Conversation
…ajor
Investigated whether we can get on TypeScript 7 (the native Go compiler, ~10x
faster). Finding: we ALREADY are, for what matters.
- The TYPECHECK already runs on TS7 native — `@typescript/native` is
`"npm:typescript@7.0.2"` (aliased), resolved by resolveTs7Tsc() to
node_modules/@typescript/native/bin/tsc (Version 7.0.2), typechecking the whole
project in ~0.9s. The speed win is captured.
- The plain `typescript` dep (6.0.3) is the JS COMPILER-API library
(ts.createSourceFile, LanguageService, the AST, preProcessFile) used
programmatically by lsp, syntax-check, dependency-analyzer, proptest, and
infer-rules/scan. TS7 native ships NO JS API — `typescript@7.0.2` exports only
{ version, versionMajorMinor } — so a 6->7 bump of THIS package nulls every
ts.* call (arch:build and typecheck both crash). It must stay on 6.x.
So the recurring dependabot `typescript` 6->7 PR (the residual of the closed
dev-toolchain group #279) is a false positive: it wants to replace the JS-API
library with an API-less stub. Add a dependabot ignore for the `typescript`
MAJOR only (patch/minor 6.x still flow) so the breaking PR stops reappearing,
with a comment recording the JS-API-vs-native split for the next reader.
No code change — this was an investigation; the conclusion is "already optimal,
guard against the false-positive bump."
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.
TL;DR: we're already on TypeScript 7 for the typecheck (the ~10× native Go compiler). The remaining
typescript6.x dep is the JS compiler-API library, which can't move to 7 — TS7-native has no JS API.I attempted the TS7 migration end to end. Findings:
Already on TS7 where it counts
@typescript/nativeis"npm:typescript@7.0.2"(an aliased dep).resolveTs7Tsc()resolves it tonode_modules/@typescript/native/bin/tsc→ Version 7.0.2, andbun run typecheckruns the whole project through it in ~0.9s. The speed win is captured.Why the plain
typescriptdep can't move to 7The
typescript(6.0.3) dependency is the JS compiler-API library —ts.createSourceFile,LanguageService, the AST guards,preProcessFile,resolveModuleName— used programmatically by lsp, syntax-check, dependency-analyzer, proptest, infer-rules/scan. TS7 is a native (Go) rewrite that ships no JS API: I bumped it and probed —typescript@7.0.2exports only{ version, versionMajorMinor }, so everyts.*call becomesundefined(arch:buildandtypecheckboth crash). It must stay on 6.x until the TS-Go project ships a JS API surface.This PR
The recurring dependabot
typescript6→7 PR (residual of the closed #279 group) is therefore a false positive — it would swap the JS-API library for an API-less stub. This adds a dependabot ignore for thetypescriptmajor only (6.x patch/minor still flow) so the breaking PR stops reappearing, with a comment recording the split for the next reader. No code change — the investigation's conclusion is "already optimal."