tsconfig.json

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src",
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "types": ["node"],
    // [commit cf71d73f8] `@objectstack/metadata-core` and `@objectstack/metadata-protocol`
    // are imported by `src/meta-delete-item-carriers.test.ts` (the real-door
    // reproduction), i.e. by the TEST program `tsconfig.test.json`, which
    // extends this file. Without these rules tsc resolves those specifiers
    // through each dependency's `exports` map — `dist/index.d.ts`, A BUILD
    // ARTIFACT — so the verdict would be about the last `pnpm build` rather
    // than about the producer's source in the checkout.
    // `check:type-source-resolution` refused exactly that — the dangerous case
    // being a typecheck that PASSES against a stale `dist` — until it was
    // retired on 2026-09-18 (#18373); no gate checks this rule now.
    //
    // ONE rule per package, not two: both publish a single entry point (their
    // `exports` maps carry only `"."` besides, for metadata-core, a `./testing`
    // subpath nothing here imports), and a rule pointing at files that are not
    // on disk is worse than absent — tsc falls back to node resolution, i.e. to
    // `dist`, silently. ⛔ Never spell a key with a star not preceded by a
    // slash (`@objectstack/metadata-core*`): it matches the bare name AND every
    // subpath, folds them onto one target, and type-checks green against the
    // wrong module.
    //
    // `rootDir` stays `./src`: this BUILD program excludes `**/*.test.ts`, so
    // no file in it imports either specifier and neither producer's source is
    // pulled in here. The test program that does pull them in already sets
    // `rootDir` to the workspace root.
    // [#12104] Same rule, same reason, for the three producers
    // `src/analytics-automation-json-erasure.test.ts` DRIVES to measure what
    // the five `return res.json()` methods really resolve to. That suite's
    // claim is "the annotation matches what the producer sends", so its verdict
    // must be about the producer's SOURCE; through `exports` it would be about
    // the last `pnpm build` of three other packages. Each publishes a single
    // `"."` entry point, so one bare-name rule each — no star, per the
    // paragraph above.
    // [#16534] Same rule, same reason, for the two producers
    // `src/auth-rotated-session-token.test.ts` drives: `@objectstack/plugin-auth`
    // (the real `AuthManager`, whose three routes rotate the caller's session)
    // and the identity object definitions that pipeline stores its rows in.
    // That suite's claim is "the SDK keeps the session the SERVER just handed
    // it", so its verdict has to be about the server's SOURCE; through
    // `exports` it would be about the last `pnpm build` of two other packages,
    // which the since-retired `check:type-source-resolution` reported as a NEW
    // dist-resolved type import.
    //
    // `@objectstack/platform-objects` is the one entry here spelled as a
    // SUBPATH: that package publishes eleven of them and this suite imports one
    // (`./identity`), so the rule names that subpath exactly. Still no star —
    // per the paragraph above, a bare-name star would fold all eleven onto a
    // single target and type-check green against the wrong module.
    "paths": {
      "@objectstack/plugin-auth": ["../plugins/plugin-auth/src/index.ts"],
      "@objectstack/platform-objects/identity": ["../platform-objects/src/identity/index.ts"],
      "@objectstack/metadata-core": ["../metadata-core/src/index.ts"],
      "@objectstack/metadata-protocol": ["../metadata-protocol/src/index.ts"],
      "@objectstack/rest": ["../rest/src/index.ts"],
      "@objectstack/service-analytics": ["../services/service-analytics/src/index.ts"],
      "@objectstack/service-automation": ["../services/service-automation/src/index.ts"]
    }
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", "**/*.test.ts"]
}