TypeScript 7.0 RC：先做 CI 演練，再談編譯速度
TypeScript 7.0 RC 已透過 `typescript@rc` 與 `tsc` 接近正式路徑，團隊應該在 CI 中與 TypeScript 6 並行驗證。
The practical angle is the same across teams: keep TypeScript 6 working while running TypeScript 7 RC on the same repository, then classify differences before the stable release arrives.
發生了什麼
The TypeScript team announced TypeScript 7.0 RC on June 18, 2026. It installs as `typescript@rc` and uses the `tsc` executable, unlike earlier beta testing that centered on `@typescript/native-preview` and `tsgo`.
The release is based on a Go port of the existing TypeScript implementation. The team says the goal is semantic compatibility with TypeScript 6.0, while adding native-code performance and parallelism.
For transition, `@typescript/typescript6` provides a `tsc6` executable and keeps the TypeScript 6 API available for tools that are not ready for the new API story.
為什麼重要
TypeScript is not only a compiler. It is also a language server and an API that many linting, documentation, code generation, and testing tools use. A migration must therefore test code, tools, editor behavior, and CI resources separately.
The RC window is valuable because the stable release is planned soon, but blockers can still be reported or documented. Teams should collect their own failure inventory instead of waiting for the ecosystem to decide for them.
Configuration changes inherited from TypeScript 6.0 can be the real migration work: `rootDir`, `types`, module settings, unsupported legacy targets, and JavaScript/JSDoc behavior all deserve an explicit pass.
社群訊號
Community discussion shows excitement around faster feedback loops and caution around tool compatibility. Treat that as a practitioner signal, not as a factual source for release claims.
Tooling projects that depend on the TypeScript API may need more time, because the RC post says a stable programmatic API is not expected until at least TypeScript 7.1.
對開發與營運的影響
Add a non-blocking CI job first. Run TypeScript 6 and TypeScript 7 RC on the same commit, compare results, and classify failures before making the new compiler required.
Tune `--checkers` and `--builders` for CI machines, not just local laptops. More parallelism can be faster, but it can also create memory pressure on small runners.
Try the editor preview on real workspaces and verify everyday actions such as auto-imports, hovers, code lenses, sort imports, and remove-unused-imports.
實務清單
✓ 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.
風險與反方觀點
The main risk is upgrading the compiler while the surrounding toolchain still expects the TypeScript 6 API. Custom transformers, TypeDoc, and type-driven codegen should be audited separately.
Another risk is treating speed as proof of correctness. RC builds are for feedback; keep TypeScript 6 available until the team knows which failures are real blockers.
The safest path is a daily rehearsal: measure gains, record failures, and decide where TypeScript 6 must remain until the ecosystem catches up.