TypeScript 7.0 RC: start the CI rehearsal before chasing compiler speed
TypeScript 7.0 RC is out. The headline is the Go-based native compiler, but the useful engineering move today is not posting another speed screenshot. RC means the migration has entered release rehearsal. Installing `typescript@rc` now gives you the new compiler through `tsc`, and the stable release is expected to occupy that same path soon.
This blog already covered the TypeScript 7 beta and `tsgo` from a validation-first angle. The RC changes the posture. Package names, executable names, side-by-side TypeScript 6 support, parallelism controls, and hard-error behavior are now concrete enough that teams can test the transition in actual repositories instead of treating it as a preview curiosity.
What happened
On June 18, 2026, the TypeScript team announced the TypeScript 7.0 Release Candidate. It can be installed with `npm install -D typescript@rc`, and `npx tsc --version` reports a 7.0 RC build. That matters because the experiment has moved from the beta-era `@typescript/native-preview` and `tsgo` path toward the normal `typescript` package and `tsc` entry point.
TypeScript 7.0 is built on a Go port of the existing TypeScript implementation. The team describes it as a methodical port rather than a clean-room rewrite, with type-checking semantics intended to match TypeScript 6.0. The official post says it has been exercised against the long-running TypeScript test suite and large internal and external codebases.
The side-by-side story is also clearer. Teams that need TypeScript 7 `tsc` while keeping tools on the TypeScript 6 API can use `@typescript/typescript6`, which exposes `tsc6` and re-exports the 6.0 API. Because some tools import `typescript` through peer dependencies, the post also suggests npm alias patterns for maintaining the old API while separately invoking the 7 RC compiler.
Why it matters
Compiler speed is a major productivity lever in large repositories, but speed alone is not a migration plan. TypeScript is a language, a build tool, an editor language service, and an API surface that ESLint integrations, documentation generators, test tooling, transformers, and code generators often assume. A responsible migration separates “does my code compile?” from “does my toolchain still behave the same way?”
The RC is the right moment to gather real CI data before the stable release. The official post says the current plan is to release TypeScript 7.0 within the next month. Treat that as a planning signal, not a contractual deadline. If the RC exposes a blocker now, teams still have time to file upstream issues, create internal migration tasks, or decide which packages must stay on TypeScript 6 for longer.
The other practical issue is that TypeScript 7.0 carries TypeScript 6.0 defaults and turns a set of deprecated flags and constructs into hard errors. Settings such as `strict`, `module`, `target`, `noUncheckedSideEffectImports`, `types`, and `rootDir` can create more immediate work than the compiler port itself. The `rootDir` and `types` changes are especially likely to surprise monorepos and test environments that rely on implicit global types.
Community signals
Developer discussion has split into two useful signals: people are excited about enough speed to change pre-commit and editor workflows, and they are cautious about the ecosystem that imports the TypeScript API directly. Community posts are not factual sources for Microsoft’s claims, but they are a good signal of what practitioners are actually worried about: tool compatibility, rollout timing, and how long a TypeScript 6 lane remains practical.
The TypeDoc tracking issue around native TypeScript is a good example of the second signal. TypeScript 7.0 is close enough for CLI and language-server testing, but the official RC post says a stable programmatic API is not expected until at least TypeScript 7.1. Application teams can start CI rehearsals now; tooling authors and plugin-heavy organizations should expect a longer coexistence period.
Development and operations impact
The first engineering impact is CI design. Do not replace the existing `tsc --noEmit` job immediately. Add a separate job that runs TypeScript 6 and TypeScript 7 RC on the same commit. When results differ, classify the failure before blocking the build: real type behavior, TypeScript 6 default adoption, JS/JSDoc analysis changes, TypeScript API dependency, or resource pressure.
The second impact is resource tuning. TypeScript 7.0 parallelizes parts of parsing, type-checking, emitting, and project reference builds. `--checkers` controls the number of type-checking workers, and `--builders` controls parallel project-reference builders. Large monorepos may benefit significantly, but small CI runners can hit CPU and memory contention. In CI, the goal is a reproducible fixed configuration, not the fastest one discovered on a developer workstation.
The third impact is editor rollout. VS Code users can try the TypeScript Native Preview extension, and the new foundation speaks LSP. Faster editor feedback can be a major day-to-day improvement, but teams should still verify auto-imports, semantic highlighting, sort imports, remove unused imports, hovers, and code lenses on real workspaces before declaring the migration done.
Practical checklist
✓ Add a separate CI job that runs TypeScript 6 and TypeScript 7 RC side by side.
✓ Scan tsconfig usage for rootDir, types, moduleResolution, target, baseUrl, and deprecated flags first.
✓ Treat JavaScript and JSDoc-heavy projects as higher-risk than straightforward .ts projects.
✓ Experiment with fixed --checkers and --builders values based on CI CPU and memory limits.
✓ Audit tools that import the TypeScript API directly, such as typescript-eslint, TypeDoc, transformers, and code generators.
✓ Classify failures as compile behavior, tool API dependency, performance/memory, or editor UX before assigning owners.
Risks and counterarguments
The counterargument is straightforward: not every team should promote an RC to a required production gate immediately. If your stack depends heavily on the TypeScript programmatic API, custom transformers, TypeDoc plugins, or type-driven code generation, you may need to keep a TypeScript 6 lane even after TypeScript 7 reaches stable.
Another risk is letting the speed story hide quality or compatibility regressions. The official post emphasizes semantic compatibility, but an RC is still a feedback release. Different `--checkers` values can expose rare order-dependent behavior, and the reworked JavaScript support can reject JSDoc patterns that older TypeScript accepted.
The pragmatic conclusion is to add TypeScript 7.0 RC as a daily rehearsal, not as the only compiler overnight. If it passes, measure the speed and editor gains. If it fails, classify the failures and document where TypeScript 6 must remain. The teams that will move calmly when stable lands are the teams that build the failure inventory during the RC window.