declapract-typescript-ehmpathy 0.49.9 → 0.49.11

package/dist/practices/tests-expo/best-practice/jest.unit.env.ts

@@ -0,0 +1,18 @@
+import util from 'node:util';
+
+// provide fetch for the test env, like the browser/native runtime does
+import 'isomorphic-fetch';
+
+// set console.log to not truncate nested objects
+util.inspect.defaultOptions.depth = 5;
+
+// react-test-renderer 19 requires this flag to run act() cleanly
+(globalThis as { IS_REACT_ACT_ENVIRONMENT?: boolean }).IS_REACT_ACT_ENVIRONMENT =
+  true;
+
+/**
+ * sanity check that unit tests only run in the 'test' environment
+ * .why = prevent prod state pollution + financial mutations from test data
+ */
+if (process.env.NODE_ENV !== 'test' && process.env.I_KNOW_THE_RISKS !== 'true')
+  throw new Error(`unit-test does not target stage 'test'`);

package/dist/practices/tests-expo/best-practice/package.json

@@ -0,0 +1,9 @@
+{
+  "devDependencies": {
+    "jest-expo": "@declapract{check.minVersion('54.0.0')}",
+    "@babel/core": "@declapract{check.minVersion('7.24.0')}",
+    "babel-preset-expo": "@declapract{check.minVersion('12.0.0')}",
+    "react-test-renderer": "@declapract{check.minVersion('19.0.0')}",
+    "isomorphic-fetch": "@declapract{check.minVersion('3.0.0')}"
+  }
+}

package/dist/practices/tests-expo/best-practice/package.json.declapract.ts

@@ -0,0 +1,16 @@
+import { FileCheckType } from 'declapract';
+
+/**
+ * .what = the expo half of the tests triad: the jest-expo transform stack that
+ *         replaces node's `@swc/jest`.
+ * .why  = an expo app's tests must transform react-native + expo ESM through
+ *         babel-preset-expo (metro's transform), which jest-expo wires up. these deps
+ *         track the installed expo SDK major (jest-expo 54 pairs with expo 54), so the
+ *         floors are minima, not pins — a repo on a newer SDK bumps them.
+ *
+ * .caveat = these versions are SDK-coupled and un-validatable without a live expo repo;
+ *           the emit is proven at the declapract-emit bar (the integration test), the
+ *           live jest-expo run is proven against a real expo repo per the wisher's
+ *           accepted validation bar for this fork.
+ */
+export const check = FileCheckType.CONTAINS;

package/dist/practices/tests-node/bad-practices/babel/babel.config.js.declapract.ts

@@ -0,0 +1,3 @@
+import { FileCheckType } from 'declapract';
+
+export const check = FileCheckType.EXISTS;

package/dist/practices/tests-node/bad-practices/deprecated-test-deps/package.json.declapract.ts

@@ -0,0 +1,50 @@
+import { FileCheckType, type FileFixFunction } from 'declapract';
+
+export const check = FileCheckType.CONTAINS;
+
+const deprecatedDeps = [
+  'babel-jest',
+  '@babel/core',
+  '@babel/preset-env',
+  'core-js',
+  'ts-jest',
+];
+
+/**
+ * .what = returns a deps map with every deprecated key removed, without any mutation
+ * .why  = the fix strips deprecated test deps; rule.require.immutable-vars forbids a
+ *         delete-in-place on the copied deps object, so it filters into a fresh map instead
+ */
+const withoutDeprecatedDeps = (
+  deps: Record<string, string> | undefined,
+): Record<string, string> =>
+  Object.fromEntries(
+    Object.entries(deps ?? {}).filter(([dep]) => !deprecatedDeps.includes(dep)),
+  );
+
+/**
+ * .what = removes the deprecated node-jest test deps from a package.json's
+ *         dependencies + devDependencies
+ * .why  = deps like babel-jest, ts-jest, @babel/* belong to the retired node-jest
+ *         toolchain; a repo on the @swc/jest config no longer needs them, so this
+ *         bad-practice fix drops them
+ */
+export const fix: FileFixFunction = (contents) => {
+  if (!contents) return { contents }; // no-op when the file is absent
+  const packageJSON = JSON.parse(contents);
+
+  // remove deprecated deps from devDependencies + dependencies (non-mutating filter)
+  const updatedDevDeps = withoutDeprecatedDeps(packageJSON.devDependencies);
+  const updatedDeps = withoutDeprecatedDeps(packageJSON.dependencies);
+
+  const updatedPackageJSON = {
+    ...packageJSON,
+    dependencies: Object.keys(updatedDeps).length > 0 ? updatedDeps : undefined,
+    devDependencies:
+      Object.keys(updatedDevDeps).length > 0 ? updatedDevDeps : undefined,
+  };
+
+  return {
+    contents: JSON.stringify(updatedPackageJSON, null, 2),
+  };
+};

package/dist/practices/tests-node/best-practice/jest.config.ts

@@ -0,0 +1,7 @@
+/**
+ * @jest-config-loader esbuild-register
+ */
+import config from './jest.unit.config';
+
+// eslint-disable-next-line import/no-default-export
+export default config;

package/dist/practices/tests-node/best-practice/jest.unit.env.ts.declapract.ts

@@ -0,0 +1,39 @@
+// eslint-disable-next-line import/no-extraneous-dependencies
+
+import type { FileContentsFunction } from 'declapract';
+import { FileCheckType } from 'declapract';
+
+import { readFile } from '../../../utils/readFile';
+
+/**
+ * .what = declare the jest unit-env file, with the config mock block included only when the
+ *         `config` practice is in play for the project.
+ * .why  = the mock stubs `getConfig` to return plaintext test config; a project WITHOUT the
+ *         `config` practice has no such module to mock, so the stub would reference a file that is
+ *         absent. a branch on `context.projectPractices` lets one practice serve both.
+ */
+export const contents: FileContentsFunction = async (context) => {
+  // grab the superset of best practices content
+  const contentsSuperset = await readFile(`${__dirname}/jest.unit.env.ts`);
+
+  // remove the config mock block when the config practice is absent — immutable const, no reassign
+  const contents = context.projectPractices.includes('config')
+    ? contentsSuperset
+    : contentsSuperset.replace(
+        `// mock that getConfig just returns plaintext test env config in unit tests
+jest.mock('./src/utils/config/getConfig', () => ({
+  getConfig: jest.fn().mockImplementation(() => require('./config/test.json')),
+}));
+
+`,
+        '',
+      );
+
+  // return the narrowed contents
+  return contents;
+};
+
+/**
+ * check that they're contained in the file
+ */
+export const check: FileCheckType = FileCheckType.CONTAINS;

package/dist/practices/tests-node/best-practice/package.json

@@ -0,0 +1,6 @@
+{
+  "devDependencies": {
+    "@swc/core": "@declapract{check.minVersion('1.15.3')}",
+    "@swc/jest": "@declapract{check.minVersion('0.2.39')}"
+  }
+}

package/dist/practices/tests-node/best-practice/package.json.declapract.ts

@@ -0,0 +1,10 @@
+import { FileCheckType } from 'declapract';
+
+/**
+ * .what = the node half of the tests triad: the `@swc/jest` transform deps that the
+ *         node jest configs use.
+ * .why  = node unit/integration/acceptance jest configs transform via `@swc/jest`
+ *         (fast, node-target). the expo half transforms via jest-expo/babel instead,
+ *         so these deps are node-only. CONTAINS, so a repo may add more.
+ */
+export const check = FileCheckType.CONTAINS;

package/dist/practices/typescript-any/bad-practices/relative-imports/.declapract.readme.md

@@ -0,0 +1,45 @@
+this bad practice detects relative imports that traverse up directories (`../`) and can be replaced with the `@src/` path alias.
+
+why this matters:
+- relative paths are fragile and break when files are moved or reorganized
+- `@src/` alias provides stable, absolute imports from the src root
+- enables easier refactoring and code navigation
+- imports remain correct regardless of file location
+
+what it catches:
+- imports using `../` (e.g., `from '../utils/helper'`)
+- deeply nested relative imports (e.g., `from '../../../domain/objects'`)
+
+what it ignores:
+- same-directory imports (`./`) which are appropriate for local modules
+- files outside `src/` directory
+- imports already using `@src/` alias
+
+the fix automatically rewrites:
+```typescript
+// before
+import { helper } from '../utils/helper';
+import { thing } from '../../shared/thing';
+
+// after
+import { helper } from '@src/utils/helper';
+import { thing } from '@src/shared/thing';
+```
+
+## two-pass migration + the `directory-structure-src` pair
+
+a file still under a deprecated src dir (`logic/`, `data/`, `domain/`, `model/`, `services/`,
+`__nonpublished_modules__/`) is **deferred** this pass — the rewrite is held to the next `declapract
+fix` pass, once the file sits at its new path. this is because `directory-structure-src`'s
+`old-*-dir` bad-practices RELOCATE that file in the same pass, and a relocate plus an in-place
+rewrite of one file in one apply throws ENOENT on the unlinked source. both practices share the
+guard via `src/utils/isDeferredToDeprecatedDirMove.ts`, so they cannot drift.
+
+two consequences a consumer should know:
+
+- **run `declapract fix` twice** on a repo that still holds deprecated-dir files: pass 1 relocates,
+  pass 2 rewrites the moved files' imports at their new path.
+- **this practice pairs with `directory-structure-src`.** the deferral only completes if
+  `directory-structure-src` is also in the usecase to perform the relocate. every usecase that
+  declares `typescript-any` today also declares `directory-structure-src`; keep them together, or a
+  deferred file is never moved and its rewrite never fires.

package/dist/practices/typescript-any/bad-practices/relative-imports/src/<star><star>/<star>.ts.declapract.ts

@@ -0,0 +1,97 @@
+import type { FileCheckFunction, FileFixFunction } from 'declapract';
+
+import { isDeferredToDeprecatedDirMove } from '../../../../../../utils/isDeferredToDeprecatedDirMove';
+
+/**
+ * .what = detects relative imports that should use @src alias
+ * .why = relative paths are fragile and break when files move
+ */
+
+// matches relative imports that go up directories (../)
+const RELATIVE_IMPORT_PATTERN = /from\s+['"](\.\.\/)+(.*?)['"]/g;
+
+const isInPracticesDir = (relativeFilePath: string | undefined): boolean =>
+  relativeFilePath?.includes('src/practices/') ?? false;
+
+const isDeclapractFile = (relativeFilePath: string | undefined): boolean =>
+  relativeFilePath?.endsWith('.declapract.ts') ?? false;
+
+/**
+ * skip files in src/practices/ because they are templates defining what target
+ * codebases should look like - not actual config files to be fixed. however,
+ * .declapract.ts files contain check/fix logic (not template content) so they
+ * should still be processed normally by other practices.
+ */
+const shouldSkip = (relativeFilePath: string | undefined): boolean =>
+  isInPracticesDir(relativeFilePath) && !isDeclapractFile(relativeFilePath);
+
+export const check: FileCheckFunction = (contents, { relativeFilePath }) => {
+  if (!contents) throw new Error('does not match bad practice');
+
+  // skip if file is not in src/
+  if (!relativeFilePath?.startsWith('src/')) {
+    throw new Error('does not match bad practice');
+  }
+
+  // skip practice template files
+  if (shouldSkip(relativeFilePath)) {
+    throw new Error('does not match bad practice');
+  }
+
+  // defer a file still under a deprecated dir to its peer dir-move: the move
+  // relocates it this pass, then this rewrite fires at the new path next pass.
+  // the two never touch one file in one apply, so no relocate+rewrite ENOENT.
+  if (isDeferredToDeprecatedDirMove({ relativeFilePath }))
+    throw new Error('deferred to peer dir-move this pass');
+
+  // check for relative imports that go up directories (../)
+  const matches = contents.match(RELATIVE_IMPORT_PATTERN);
+  if (matches && matches.length > 0) {
+    return; // matches bad practice
+  }
+
+  throw new Error('does not match bad practice');
+};
+
+export const fix: FileFixFunction = (contents, { relativeFilePath }) => {
+  if (!contents) return {};
+  if (!relativeFilePath?.startsWith('src/')) return {};
+  if (shouldSkip(relativeFilePath)) return {};
+
+  // defer a file still under a deprecated dir to its peer dir-move (see check)
+  if (isDeferredToDeprecatedDirMove({ relativeFilePath })) return {};
+
+  // calculate the path parts of the current file
+  const pathParts = relativeFilePath.split('/');
+  const srcIndex = pathParts.indexOf('src');
+
+  // get the directories between src/ and the current file
+  const currentDirParts = pathParts.slice(srcIndex + 1, -1);
+
+  // replace relative imports with @src imports (only if they stay within src/)
+  const fixed = contents.replace(
+    /from\s+['"]((\.\.\/)+)(.*?)['"]/g,
+    (match, dots, _, importPath) => {
+      // count how many ../ we have
+      const upCount = (dots.match(/\.\.\//g) || []).length;
+
+      // if going up more levels than we have directories within src/, it goes OUTSIDE src
+      // leave these imports unchanged (e.g., ../../package.json from src/utils/index.ts)
+      if (upCount > currentDirParts.length) {
+        return match;
+      }
+
+      // if going up exactly as many levels as we have directories, target is at src root
+      if (upCount === currentDirParts.length) {
+        return `from '@src/${importPath}'`;
+      }
+
+      // otherwise, calculate the remaining path after going up
+      const remainingParts = currentDirParts.slice(0, -upCount);
+      const targetPath = [...remainingParts, importPath].join('/');
+      return `from '@src/${targetPath}'`;
+    },
+  );
+
+  return { contents: fixed };
+};

package/dist/practices/typescript-any/best-practice/.declapract.readme.md

@@ -0,0 +1,17 @@
+this bundle defines the runtime-agnostic half of the typescript triad: the shared
+typecheck that every runtime runs, regardless of how it builds or bundles.
+
+namely:
+- the `test:types` command — `tsc -p ./tsconfig.json --noEmit`
+  - typechecks without a build, so it runs the same on node and expo
+  - the runtime halves (`typescript-node`, `typescript-expo`) ship the tsconfig it points at
+- the `typescript` dev dependency, pinned to a shared floor
+
+why a runtime-agnostic half:
+- the typecheck is identical across runtimes; only the build/bundle differs
+- so the shared command + dep live here, and each runtime half declares only its own
+  tsconfig + build (tsc-alias for node, metro/expo for expo)
+
+see the runtime halves for the build-specific config:
+- `typescript-node` — node16 tsconfig + `tsc` + `tsc-alias` post-compilation build
+- `typescript-expo` — `expo/tsconfig.base` + `expo export`, bundled by metro (no tsc build)

package/dist/practices/typescript-any/best-practice/package.json

@@ -0,0 +1,8 @@
+{
+  "devDependencies": {
+    "typescript": "@declapract{check.minVersion('5.4.5')}"
+  },
+  "scripts": {
+    "test:types": "tsc -p ./tsconfig.json --noEmit"
+  }
+}

package/dist/practices/typescript-any/best-practice/package.json.declapract.ts

@@ -0,0 +1,11 @@
+import { FileCheckType } from 'declapract';
+
+/**
+ * .what = the runtime-agnostic half of the typescript triad: the `typescript` dep
+ *         + the `tsc --noEmit` typecheck command
+ * .why  = the typecheck emits no output, so it is bound to no bundler and runs on any
+ *         runtime. the tsconfig.json it points at is supplied by the runtime half
+ *         (typescript-node or typescript-expo), so this practice pairs with exactly
+ *         one of them per usecase.
+ */
+export const check = FileCheckType.CONTAINS;

package/dist/practices/typescript-expo/best-practice/package.json

@@ -0,0 +1,6 @@
+{
+  "scripts": {
+    "build": "npm run build:web",
+    "build:web": "npx expo export --platform web"
+  }
+}

package/dist/practices/typescript-expo/best-practice/package.json.declapract.integration.test.ts

@@ -0,0 +1,30 @@
+import { FileCheckType } from 'declapract';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+
+import { check } from './package.json.declapract';
+
+/**
+ * .why integration = the build-command assertions read the shipped `package.json` template
+ *   from disk via readFileSync — a filesystem boundary. per rule.forbid.unit.remote-boundaries
+ *   a `.test.ts` (unit) may not cross an fs boundary, so this guard (which exists to catch
+ *   DRIFT in the real template's build commands) lives at the integration grain, where a real
+ *   file read is permitted. an inline copy would test a hardcoded string, not the template,
+ *   so it could not catch the drift this guards.
+ */
+describe('typescript-expo package.json', () => {
+  it('declares a CONTAINS check (a repo may add its own build variants)', () => {
+    expect(check).toEqual(FileCheckType.CONTAINS);
+  });
+
+  it('the emitted build command uses metro/EAS (expo export), not tsc', () => {
+    const template = JSON.parse(
+      readFileSync(path.join(__dirname, 'package.json'), 'utf-8'),
+    );
+    // `build` aliases build:web so the shared cicd `npm run build` works on expo
+    expect(template.scripts.build).toEqual('npm run build:web');
+    // the web build is expo export, NOT a tsc build (an expo app never builds with tsc)
+    expect(template.scripts['build:web']).toContain('expo export --platform web');
+    expect(template.scripts.build).not.toContain('tsc');
+  });
+});

package/dist/practices/typescript-expo/best-practice/package.json.declapract.ts

@@ -0,0 +1,12 @@
+import { FileCheckType } from 'declapract';
+
+/**
+ * .what = the expo half of the typescript triad: the `build` command that metro/EAS
+ *         use instead of tsc.
+ * .why  = an expo app never builds with tsc — metro bundles the native build and
+ *         `npx expo export --platform web` produces the web `dist/`. `build` aliases
+ *         `build:web` so the shared cicd-common `.test.yml` (which runs `npm run build`)
+ *         works on an expo repo, and `.deploy-expo.yml` (which runs `npm run build:web`)
+ *         works too. CONTAINS, so a repo may add its own build variants around these.
+ */
+export const check = FileCheckType.CONTAINS;

package/dist/practices/typescript-expo/best-practice/tsconfig.json

@@ -0,0 +1,14 @@
+{
+  "extends": "expo/tsconfig.base",
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": {
+      "@src/*": ["src/*"],
+      "@assets/*": ["assets/*"]
+    }
+  },
+  "include": [
+    "**/*.ts",
+    "**/*.tsx"
+  ]
+}

package/dist/practices/typescript-expo/best-practice/tsconfig.json.declapract.integration.test.ts

@@ -0,0 +1,32 @@
+import { FileCheckType } from 'declapract';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+
+import { check } from './tsconfig.json.declapract';
+
+/**
+ * .why integration = the template-content assertions read the shipped `tsconfig.json`
+ *   template from disk via readFileSync — a filesystem boundary. per
+ *   rule.forbid.unit.remote-boundaries a `.test.ts` (unit) may not cross an fs boundary,
+ *   so this guard (which exists to catch DRIFT in the real template) lives at the
+ *   integration grain, where a real file read is permitted. an inline copy would test a
+ *   hardcoded string, not the template, so it could not catch the drift this guards.
+ */
+describe('typescript-expo tsconfig.json', () => {
+  it('declares a CONTAINS check (a consumer may customize around the expo base)', () => {
+    expect(check).toEqual(FileCheckType.CONTAINS);
+  });
+
+  it('the emitted template is expo-shaped, not node', () => {
+    const template = JSON.parse(
+      readFileSync(path.join(__dirname, 'tsconfig.json'), 'utf-8'),
+    );
+    // extends the expo base (jsx + react-native resolution), NOT @tsconfig/node20
+    expect(template.extends).toEqual('expo/tsconfig.base');
+    // the core path aliases a consumer relies on
+    expect(template.compilerOptions.paths['@src/*']).toEqual(['src/*']);
+    expect(template.compilerOptions.paths['@assets/*']).toEqual(['assets/*']);
+    // tsx is included (a react-native app has jsx), unlike the node tsconfig
+    expect(template.include).toContain('**/*.tsx');
+  });
+});

package/dist/practices/typescript-expo/best-practice/tsconfig.json.declapract.ts

@@ -0,0 +1,12 @@
+import { FileCheckType } from 'declapract';
+
+/**
+ * .what = the expo tsconfig: extends `expo/tsconfig.base` (jsx, react-native module
+ *         resolution) instead of the node16 `@tsconfig/node20` base.
+ * .why  = CONTAINS, not EQUALS, so an app that has already customized its expo tsconfig
+ *         (extra paths, an app-specific include) is NOT clobbered — the check only asserts
+ *         the expo base + core `@src`/`@assets` paths are present. a greenfield expo repo
+ *         gets this emitted by `declapract fix`; a repo like app-protools-native (already
+ *         `extends: expo/tsconfig.base`) already satisfies it.
+ */
+export const check = FileCheckType.CONTAINS;

package/dist/practices/{typescript → typescript-node}/best-practice/package.json

@@ -1,6 +1,5 @@
 {
   "devDependencies": {
-    "typescript": "@declapract{check.minVersion('5.4.5')}",
     "tsc-alias": "@declapract{check.minVersion('1.8.10')}",
     "@tsconfig/node20": "@declapract{check.minVersion('20.1.5')}",
     "@tsconfig/strictest": "@declapract{check.minVersion('2.0.5')}",
@@ -12,7 +11,6 @@
     "build:clean": "npm run build:clean:tsc && npm run build:clean:bun",
     "build:compile:tsc": "tsc -p ./tsconfig.build.json && tsc-alias -p ./tsconfig.build.json",
     "build:compile": "npm run build:compile:tsc && npm run build:compile:bun --if-present",
-    "build": "npm run build:clean && npm run build:compile && npm run build:complete --if-present && npm run build:artifact",
-    "test:types": "tsc -p ./tsconfig.json --noEmit"
+    "build": "npm run build:clean && npm run build:compile && npm run build:complete --if-present && npm run build:artifact"
   }
 }

package/dist/practices/typescript-node/best-practice/package.json.declapract.ts

@@ -0,0 +1,25 @@
+import { FileCheckType, type FileContentsFunction } from 'declapract';
+
+import { readFile } from '../../../utils/readFile';
+
+/**
+ * .what = declare the node package.json, with the artifact-build clause included only when the
+ *         `artifact` practice is in play for the project.
+ * .why  = the node build chains ` && npm run build:artifact` onto its build; a project WITHOUT the
+ *         `artifact` practice has no such artifact to build, so the clause would break its build.
+ *         a branch on `context.projectPractices` lets one practice serve both (rule.avoid.runtime-forks).
+ */
+export const contents: FileContentsFunction = async (context) => {
+  // grab the superset of best practices content
+  const contentsSuperset = await readFile(`${__dirname}/package.json`);
+
+  // remove the artifact-build clause when the artifact practice is absent — immutable const, no reassign
+  const contents = context.projectPractices.includes('artifact')
+    ? contentsSuperset
+    : contentsSuperset.replace(` && npm run build:artifact`, '');
+
+  // return the narrowed contents
+  return contents;
+};
+
+export const check = FileCheckType.CONTAINS;

package/dist/practices/typescript-node/best-practice/tsconfig.json.declapract.ts

@@ -0,0 +1,3 @@
+import { FileCheckType } from 'declapract';
+
+export const check = FileCheckType.CONTAINS;

package/dist/useCases.yml

@@ -1,6 +1,18 @@
 # define the different types of combinations of the best practices that we support
 use-cases:
-  typescript-project:
+  # the runtime-agnostic platform baseline: every practice shared by a node project and an
+  # expo app alike (agent tools, package manager, domain organization, lint/format, git).
+  # extracted so `typescript-project` and `app-react-native-expo` COMPOSE it via `extends`
+  # rather than hand-copy it — a practice added HERE reaches both consumers, so neither can
+  # silently drift from the baseline (the exact bug the fix-expo wish exists to fix).
+  #
+  # .note = declapract's `extends` is NON-TRANSITIVE (it pulls a usecase's OWN base
+  #         `.practices`, never its resolved-with-extends set — see declapract#17). so a
+  #         consumer that wants this core must extend `typescript-project-core` DIRECTLY; it
+  #         cannot inherit it through a usecase that itself extends core. every consumer below
+  #         does. the `getAllPracticesForUsecase` characterization test pins every usecase's
+  #         resolved set, so this extraction is proven to change zero practice for any repo.
+  typescript-project-core:
     practices:
       - cache
       - cicd-common
@@ -16,12 +28,20 @@ use-cases:
       - nonpublished-modules
       - package-json-order
       - rhachet
-      - tests
-      - typescript
+      - tests-any
+      - typescript-any
       - pnpm
+  typescript-project:
+    extends:
+      - typescript-project-core
+    practices:
+      # the node runtime delta atop the shared core: the tsc build + node jest + rate-limit lib
+      - tests-node
+      - typescript-node
       - bottleneck
   npm-package:
     extends:
+      - typescript-project-core # non-transitive: must extend core directly (declapract#17)
       - typescript-project
     practices:
       - cicd-package
@@ -29,6 +49,7 @@ use-cases:
       - provision-github
   lambda-service:
     extends:
+      - typescript-project-core # non-transitive: must extend core directly (declapract#17)
       - typescript-project
     practices:
       - artifact
@@ -49,29 +70,28 @@ use-cases:
       - uuid
   lambda-service-with-rds:
     extends:
-      - typescript-project # https://github.com/ehmpathy/declapract/issues/17
+      - typescript-project-core # https://github.com/ehmpathy/declapract/issues/17
+      - typescript-project
       - lambda-service
     practices:
       - persist-with-rds
-  lambda-service-with-dynamodb: # note that projects can still use both by specifying the `declapract.use-case: [lambda-service-with-dynamodb, lambda-service-with-rds]` since we allow use-cases to add together. `use-cases` just enable us to enforce a "minimum" set of practices
+  lambda-service-with-dynamodb: # projects can use both at once via `declapract.use-case: [lambda-service-with-dynamodb, lambda-service-with-rds]` since use-cases add together. a use-case just enforces a "minimum" set of practices
     extends:
-      - typescript-project # https://github.com/ehmpathy/declapract/issues/17
+      - typescript-project-core # https://github.com/ehmpathy/declapract/issues/17
+      - typescript-project
       - lambda-service
     practices:
       - persist-with-dynamodb
   app-react-native-expo:
+    extends:
+      - typescript-project-core # composes the shared platform baseline; only the expo delta is listed below
     practices:
-      - cicd-common
+      # the expo runtime delta atop the shared core: the expo cicd, the metro/expo lint,
+      # and the expo cuts of the typescript/tests triads. NO terraform-common — an expo app
+      # owns no terraform-managed infra (declastruct is the go-forward; see define.declastruct-goforward.md).
       - cicd-app-react-native-expo
-      - conventional-commits
-      - husky
-      - format
-      - git
-      - node
-      - nonpublished-modules
-      - package-json-order
-      - terraform-common
       - provision-github
-      - lint
       - lint-react
       - lint-react-native
+      - tests-expo
+      - typescript-expo