chore(frontend): use TypeScript 7 native compiler for type-checking#1460
Open
danyelf wants to merge 1 commit into
Open
chore(frontend): use TypeScript 7 native compiler for type-checking#1460danyelf wants to merge 1 commit into
danyelf wants to merge 1 commit into
Conversation
Adopt the native (Go) TypeScript 7 compiler for `tsc`, which speeds up
type-checking locally and in the release-ui CI job, while keeping the
JS-based compiler available for the tools that still need its API.
TypeScript 7 is a native rewrite that ships no programmatic API until
7.1, so a bare `typescript@7` breaks Next's build-time type check and
tsdown's .d.ts generation (both call `require('typescript')`). The fix
is Microsoft's recommended dual-install:
- `typescript` -> npm:@typescript/typescript6 (JS 6.x, keeps the API;
binary is `tsc6`)
- `typescript-7` -> npm:typescript@7 (native; provides the `tsc` binary
that `pnpm type:check` runs)
Net effect: `pnpm type:check` (and CI's release-ui type-check step) now
run the fast native compiler, and Next/tsdown keep working against the
JS API. On this repo `tsc --noEmit` drops from ~2.3-6.2s (JS) to ~0.9s
(native). No CI workflow change is needed -- the alias makes `tsc`
resolve to the native binary; the lockfile records all platform builds
so `--frozen-lockfile` on the Linux runner pulls the right one.
Three version pins move together: the two devDependencies (root and
packages/ui) plus the `typescript:` override in pnpm-workspace.yaml.
Documented in js/CLAUDE.md so the alias isn't mistaken for a mistake.
Verified: lint, type:check, tsdown build, next build, 4042 vitest tests,
and a frozen-lockfile install all pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Danyel Fisher <danyel@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR checklist
What type of PR is this?
chore— frontend build tooling / dependencies.What this PR does / why we need it:
TypeScript 7 shipped — it's the native (Go) compiler and is dramatically faster than the JS-based
tsc. This adopts it for type-checking, both locally and in CI, without breaking the build tools that still depend on the old compiler's API.The catch: TypeScript 7.0 ships no programmatic API (a new one is slated for 7.1). Anything that does
require('typescript')— Next.js's build-time type check and tsdown's.d.tsgeneration — breaks on a baretypescript@7. So a naive bump is a non-starter.The fix is Microsoft's recommended dual-install, which keeps both compilers side by side:
typescript→npm:@typescript/typescript6— the JS-based 6.x compiler. Keeps the programmatic API alive for Next and tsdown. Its binary is exposed astsc6.typescript-7→npm:typescript@7— the native compiler. Provides thetscbinary thatpnpm type:checkruns.Net effect:
pnpm type:check— locally and in therelease-uiCI job — now runs the fast native compiler, while Next's build and the@datarecce/ui.d.tsbuild keep working against the JS API. On this repo,tsc --noEmitdrops from ~2.3–6.2s (JS) to ~0.9s (native).No CI workflow file changes are needed: the alias makes
tscresolve to the native binary automatically, and the lockfile records all platform builds sopnpm install --frozen-lockfileon the Linux runner pulls the correct one (@typescript/typescript-linux-x64).Which issue(s) this PR fixes:
None — opportunistic tooling upgrade.
Special notes for your reviewer:
typescriptdevDependencies (rootjs/package.jsonandjs/packages/ui/package.json) and thetypescript:override injs/pnpm-workspace.yaml. Reverting any to a plaintypescript@7reintroduces the no-API breakage. This is documented injs/CLAUDE.md.pnpm lint,pnpm type:check,pnpm test(4042 pass),pnpm run build(Next + tsdown), andCI=true pnpm install --frozen-lockfileall pass.Does this PR introduce a user-facing change?:
NONE