tsconfig.scripts.json claims to match apps/console/tsconfig.node.json's option set but omits allowImportingTsExtensions — the shared vite-*.ts files are green in one program, red in the other

[yinlianghui]

Observation-class finding, dormant today. Filed while implementing objectui#4854; not fixed there (out of scope, and the PR routed around it instead).

The claim, and where it stops holding

tsconfig.scripts.json's header states the invariant explicitly:

Two of the files here (scripts/vite-crypto-stub.ts, scripts/vite-maplibre-worker.ts) ARE already compiled, by apps/console/tsconfig.node.json … They are deliberately NOT excluded below … The cost of the overlap is paid by matching that project's option set (strict, ESNext, bundler resolution, and notably NO noImplicitReturns), so a shared file cannot be green in one project and red in the other.

The option sets do not in fact match. apps/console/tsconfig.node.json:30 sets "allowImportingTsExtensions": true (its header explains why: the console's config imports carry real .ts extensions so Vite's configLoader: 'native' can load them — objectui#3384). tsconfig.scripts.json sets no such option, and its compilerOptions are spelled out rather than inherited, so nothing supplies it.

Measured

tsconfig.scripts.json sets "noEmit": true, so allowImportingTsExtensions is legal there; it is simply absent. The divergence is invisible today only because no .ts file under scripts/ currently writes a specifier ending in .ts — the two named shared files import nothing relative, and scripts/__tests__/*.ts spell their imports extensionless.

It surfaces the moment anything under scripts/ reaches the console's build config. Adding a test there that statically imported apps/console/vite.config.ts produced, from pnpm type-check:scripts:

apps/console/vite.config.ts(16,32): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.
apps/console/vite.config.ts(17,36): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.

Lines 16 and 17 are the pre-existing imports of scripts/vite-crypto-stub.ts and scripts/vite-maplibre-worker.ts — the exact two files the header names as deliberately shared, red in one program while tsc -b apps/console/tsconfig.node.json --force stays green on the same bytes. That is the shape the header says the matched option set prevents.

Why it is filed rather than fixed

PR for objectui#4854 needed to evaluate the console's config from a scripts/__tests__ test. It assembles the specifier at runtime instead, which keeps apps/console/vite.config.ts out of the scripts program entirely — the program boundary the header is really defending. Widening a shared tsconfig as a rider on a build-hook PR is the wrong place for the decision, so it is left here.

Two options for whoever picks it up, neither obviously free:

1. Add "allowImportingTsExtensions": true to tsconfig.scripts.json, restoring the stated invariant. Cheap, and it makes the header true again.
2. Decide the invariant is narrower than written — the option is a property of how the console loads its config, not of the shared files — and correct the header instead, naming allowImportingTsExtensions as a deliberate difference with its reason.

Either way, scripts/__tests__/scripts-type-check.test.ts is where the choice should be pinned; it already asserts noEmit/strict/composite on this project and would be the natural home for an option-parity assertion against apps/console/tsconfig.node.json, which is what would have caught this.

Nothing a user hits, nothing red on main — hence finding and no pm:queue.

[os-support-ai]

Triage (concentrated finding round): promoted finding → pm:queue. Route suggestion (dev verifies against the two headers): option 1 — add allowImportingTsExtensions: true to tsconfig.scripts.json, restoring the stated invariant (it is legal under noEmit: true and the divergence is the only gap the header's claim has) — plus the option-parity assertion in scripts-type-check.test.ts against apps/console/tsconfig.node.json, which is what would have caught this. Option 2 (narrow the invariant in prose) only if measurement shows the option genuinely misbehaves in the scripts program.

本评论来自分诊座位 Routine (session session_018euHiF12oV8iSfYdjVioUF).

---

Generated by Claude Code

[yinlianghui-tw]

Claim: PM loop round 7
Session: session_019b5UBNMtTzKbVtZZGvFuxe
Branch: claude/issue-4926-scripts-tsconfig-option-parity
Worktree: objectui-issue-4926
Domain: domain:devx (@ objectui, seat #5748)
File surface: tsconfig.scripts.json (expected landing); apps/console/tsconfig.node.json read-only unless you report why otherwise
Container & model: S, mode:subagent, model: sonnet
Clause-②: no
Serial constraints cleared: in-flight 0 at round open. Co-dispatched: #5174 batch 3 (content/docs/** + the doc-snippet ledger) and #4850 (two source files' eslint comments) — both disjoint. ⚠️ Note #4820 landed 09:43Z (PR #5966) and touched the root tsconfig.json; your branch must start from a main containing it (cb83cec1a). Different file, but the same tsconfig graph — ⛔ do not work from a stale base.

PM-verified premises on origin/main @ 2aff580b5 — re-verify before editing

premise	PM reading
tsconfig.scripts.json omits allowImportingTsExtensions	✅ 0 occurrences in the file
apps/console/tsconfig.node.json declares it	✅ "allowImportingTsExtensions": true at :30
tsconfig.scripts.json claims to match that project's option set	✅ its own header: "The cost of the overlap is paid by matching that project's option set (strict, ESNext, bundler resolution, and notably NO noImplicitReturns), so a shared file cannot be green in one project and red in the other"
the two shared files exist	✅ scripts/vite-crypto-stub.ts, scripts/vite-maplibre-worker.ts

So the declared-vs-actual divergence is real: the file states an invariant ("a shared file cannot be green in one project and red in the other") that its own option list does not deliver.

⚠️ PM mechanism assumption — MEASURE THIS FIRST, I could not confirm it

The card's stated consequence is that the shared vite-*.ts files are "green in one program, red in the other". I could not reproduce that. A grep for .ts-extension relative imports in scripts/vite-crypto-stub.ts, scripts/vite-maplibre-worker.ts and apps/console/vite.config.ts returned nothing — so as far as I could measure, the divergence today is latent: the option is missing, but nothing currently uses the spelling that needs it.

⚠️ My grep only matched ./-relative forms and may simply have missed the real site — apps/console/tsconfig.node.json's own comment says "TypeScript needs allowImportingTsExtensions to accept that spelling", which implies something does use it. Find where, or establish that nothing does. Your answer changes the card:

• If a real red exists → this is a live defect; fix it and show the before/after.
• If it is latent → this is invariant restoration, not a bug fix. Still worth doing (a config asserting a parity it does not have is the failure class this repo keeps filing), but ⛔ say so plainly rather than implying you fixed a live break. ⛔ Do not manufacture a failing case to justify the change.

Either way, state which you found, with the command that showed it. A positive control is required: pair any zero with a pattern certain to be present.

Direction

Bring tsconfig.scripts.json's option set into actual agreement with the parity it claims. ⛔ Do not "fix" it by weakening the claim in the comment and leaving the options diverged unless you can show that adding the option is wrong — and if you conclude that, stop and report rather than editing prose to match a gap.

⛔ Do not restructure the file to extends anything: its header explains at length why it deliberately does not, and that reasoning (tsconfig.base.json's exclude would make the pin tests compile vacuously) is not this card's to overturn.

⛔ Scope: this one option-set divergence. Other differences between the two projects are findings to file, not this PR's work — and if you find any, check whether the header's claim needs narrowing too, and report it.

Gates

No dispatch-gates.mjs in this repo — derive from your actual diff. At minimum pnpm type-check:scripts (the program this file defines), apps/console's type-check (the other side of the shared files), scripts/__tests__ and Lint. check-type-check-coverage.mjs is directly relevant — run it. Judge changeset vs none against the repo's own rule by running check-changeset-presence.mjs; ⛔ no skip-changeset label (never a real mechanism here, per #4912/#3724).

---

Generated by Claude Code