tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "skipLibCheck": true,
    "noEmit": true,
    "types": [
      "node"
    ],
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "incremental": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "react-jsx",
    "plugins": [
      {
        "name": "next"
      }
    ],
    // TypeScript 7's NodeNext resolver can't find subpath imports like
    // `next/navigation` in packages without an "exports" map (next@16.2.12
    // has none) — it only checks ancestor node_modules for a literal
    // `next/navigation` package folder, never the sibling .d.ts file. This
    // paths mapping is a targeted workaround, not a resolution-mode change.
    //
    // `next/headers` deliberately has NO entry here. Turbopack (unlike plain
    // `tsc`) honours tsconfig `paths` for its OWN module resolution, so a
    // mapping that points at a .d.ts resolves the runtime import to a
    // type-only file with no exports — the call then compiles to `(void 0)()`.
    // Independently re-verified 2026-08-13: with the paths entry + a public
    // `next/headers` import, GET /admin returns 500
    // `TypeError: (void 0) is not a function`; with the deep import below and
    // no entry, GET /admin returns 200.
    //
    // ⚠️ THE SAME TRAP APPLIES TO `next/navigation` ABOVE. The mapping is safe
    // only for the exports we currently import through it that are erased or
    // resolved elsewhere at runtime (`redirect`, `notFound` in server
    // components). Importing a genuine client-runtime value through it breaks
    // identically: `useRouter` from `next/navigation` 500s under Turbopack dev
    // (found by an end-to-end smoke test, 2026-08-13). ANY new runtime
    // import from these packages needs the deep-import treatment:
    //   headers   → next/dist/server/request/headers.js
    //   useRouter → next/dist/client/components/navigation.js
    // Current deep-import sites: app/admin/layout.tsx, app/admin/actions.ts,
    // app/admin/compose-form.tsx, app/admin/review/[id]/publish-control.tsx.
    // RE-TEST ON NEXT UPGRADE: if the public specifiers ever type-check under
    // NodeNext, drop the mapping and all deep imports together.
    "paths": {
      "next/navigation": ["./node_modules/next/navigation.d.ts"]
    }
  },
  "include": [
    "src",
    "test",
    "app",
    "instrumentation.ts",
    // Root-level files are not covered by the "src"/"app" entries above and must
    // be listed explicitly, or they are never type-checked. middleware.ts is the
    // trust boundary for admin identity, so it must not go unchecked.
    "middleware.ts",
    // Netlify functions live outside src/ and are not covered by the "src"
    // entry above; without an explicit entry they typecheck only when they
    // happen to run, which has already bitten this project twice.
    "netlify",
    // Operator scripts (scripts/*.ts) run directly against the
    // internet-exposed VM Postgres — the same class of "never typechecked
    // until it happens to run" gap as netlify above, but with worse
    // consequences: an unnoticed type error here surfaces as a live
    // operator mistake against production data, not a caught build failure.
    "scripts",
    "next-env.d.ts",
    ".next/types/**/*.ts",
    ".next/dev/types/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}