TypeScript 7.0 RC - The Go Rewrite Reaches Release Candidate

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/

Why This Matters

TypeScript 7.0 hit Release Candidate on June 18, 2026, with stable expected within a month. This is the payoff for the bridge release we [tried and reverted on 2026-03-30](TypeScript 6 is Released) -- the compiler is no longer TypeScript-compiling-itself; it's a methodical port to Go . The headline holds: 7.0 is "often about 10 times faster" than 6.0, from native code plus shared-memory parallelism. The type-checking logic is the same as 6.0 -- they ported structure, not semantics -- so a clean 6.0 codebase should type-check identically, just far faster.
Install side-by-side without committing: npm install -D typescript@rc (the binary reports 7.0.1-rc ), and a @typescript/typescript6 shim gives you a tsc6 for A/B comparison.
But "reword all the pain points" is the right framing for this post, because the RC is mostly a list of things that used to be tolerated and are now hard errors . Here's every friction point, in plain terms.

The Pain Points, Reworded

Config defaults you relied on are now errors, not warnings

6.0 deprecated these; 7.0 deletes them. Each of the following stops your build cold:
  • target: es5 is gone. ES5 output is no longer a thing. So is downlevelIteration -- the flag only existed to make ES5 iteration work, and there's no ES5 to down-level to.
  • moduleResolution: node / node10 / classic are gone. You must be on nodenext or bundler . Classic resolution -- the pre-Node algorithm some ancient configs still carried -- is fully removed.
  • module: amd | umd | systemjs | none are unsupported. Use esnext or preserve . The pre-ESM module formats are simply not emitted anymore.
  • baseUrl is eliminated. Path mapping now resolves via paths relative to the project root. Any baseUrl -based import root has to be rewritten.
  • You can no longer turn safety off . esModuleInterop: false , allowSyntheticDefaultImports: false , and alwaysStrict: false are all disallowed -- the permissive side of these switches no longer exists.
  • module as a namespace keyword is forbidden (use namespace ), and assert on imports must become with to match the ECMAScript import-attributes standard.

New defaults will surprise an unprepared project

Even if you remove nothing, the defaults changed underneath you:
  • strict: true is now the baseline (was conditional/off).
  • module: esnext is the default (was commonjs ) -- the single most likely source of "suddenly everything is an ESM error."
  • types: [] instead of the old implicit ["*"] . TypeScript no longer auto-discovers every @types/* in node_modules ; you must list what you actually use: "types": ["node", "jest"] . This is the one most likely to break CI across the ecosystem (and, conversely, the one that speeds builds the most).
  • rootDir is no longer inferred. If your tsconfig.json sits outside your source, you now need an explicit "rootDir": "./src" and matching "include": ["./src"] .
  • noUncheckedSideEffectImports: true , libReplacement: false , and stableTypeOrdering: true (which can't be disabled) are all on by default.

Unicode now behaves correctly -- which breaks code that depended on it being broken

Template-literal type inference now splits on Unicode code points , not UTF-16 surrogate halves:
ts 
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// 7.0:        ["😀", "abc"]
// Previously: ["\ud83d", "\ude00abc"]
This is strictly more correct, but any type-level string utility that was written around the old surrogate-pair behavior will now produce different types.

JavaScript ( .js ) analysis was realigned with .ts -- old JSDoc tricks stop working

If you lean on checked JavaScript, a pile of loose patterns are gone: values can no longer stand in for types (use typeof value ), @enum JSDoc is removed (use @typedef ), bare ? is no longer a type (use any ), @class no longer turns a function into a constructor (write a real class ), postfix ! is unsupported, and Closure-style function(string): void signatures are dropped. Special handling for this -aliasing and prototype reassignment is also gone. Net: JS-with-JSDoc shops have real migration work.

The parallelism is fast but has sharp edges

The speed comes from 4 parallel type-checking workers by default ( --checkers ), plus a separate --builders flag for parallel project-reference builds -- and these multiply ( --checkers 4 --builders 4 = up to 16 concurrent checkers, which is usually too many). More cores means more speed and more memory. The subtle trap: with varying --checkers counts you can, in rare cases, surface order-dependent type-checking results -- so if cross-environment consistency matters, pin a fixed checker count everywhere (or use --singleThreaded for debugging and apples-to-apples comparison). The --watch mode was also rebuilt on Parcel's file-watcher (ported C++→Go), fixing the old node_modules polling tax.

It's an RC, so the ground is still moving

  • The programmatic compiler API is unstable until 7.1 (several months out). Anything that imports typescript as a library rather than shelling out to tsc should wait.
  • The team tracks remaining 6.0→7.0 differences in a CHANGES.md ; some JavaScript patterns are still in flux.
  • Command-line builds now require --ignoreConfig to bypass a present tsconfig.json .
  • Bugs go to the microsoft/typescript-go repo; Microsoft is explicitly asking for pre-stable feedback.

What To Watch

  • Whether our Astro toolchain peer-deps have caught up. We reverted TS 6 on 2026-03-30 because tsconfck , @astrojs/check , and svelte2tsx still pinned TS 5.x. 7.0 RC raises the same question -- the editor story now runs through the TypeScript Native Preview VS Code extension and a new multi-threaded LSP, so our astro knots sites can't adopt it until that chain moves.
  • The types: [] default breaking CI across our repos -- the most likely silent failure.
  • The one-month window to stable , and 7.1 for a stable programmatic API.
  • Real-world validation is already broad (Bloomberg, Canva, Figma, Google, Linear, Notion, Slack, Vercel, VoidZero all report ~10x), and the LSP reportedly fails 20x fewer commands than 6.0 against GitHub's top codebases -- so the question for us is ecosystem peer-deps, not compiler readiness.