TypeScript 7.0 Beta: faster builds, nastier defaults, migration tax

Parallel type-checking you can actually control

TS 7.0 parallelizes parsing, type-checking, and emitting, then exposes the knobs. Default is 4 checker workers, configurable via --checkers. Project references can also be built in parallel via --builders. The nasty part is the multiplication: --checkers 4 --builders 4 can light up up to 16 type-checkers. That’s great on a workstation with cores and RAM. On a skinny CI runner, it’s how you buy a faster failure… or an OOM. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

Gotcha: varying --checkers can surface order-dependent results. If your team doesn’t pin it, enjoy the new genre of bug report: “the error only shows up on Jenkins.” ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

Defaults that will break your build even if you never wanted TS 7

The beta adopts TS 6.0’s defaults: strict=true, module=esnext, types=[], rootDir=./, and stableTypeOrdering=true (and you can’t turn that one off). A few more land in the “surprise” bucket, like noUncheckedSideEffectImports=true. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

So what? Repos that implicitly depended on ambient globals from whatever @types happened to be installed will suddenly go red. Fix is boring and mandatory: explicitly list types. Same story for rootDir if your tsconfig.json lives outside src/. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

Deprecations stop being warnings and start being your pager

TS 7.0 turns TS 6.0 deprecations into hard errors: no target: es5, no downlevelIteration, no moduleResolution: node/node10/classic, no AMD/UMD/SystemJS module targets, and baseUrl is gone. Also, you can’t opt out of esModuleInterop/allowSyntheticDefaultImports/alwaysStrict. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

So what? This kills a lot of “ancient-but-still-running” build pipelines: legacy module formats, Node10-ish resolution behavior, and the path-alias hacks that relied on baseUrl. The maintainers explicitly don’t plan to reimplement baseUrl in 7.0. Translation: fix your paths now, or pin forever. ([github.com](https://github.com/microsoft/TypeScript/issues/62207?utm_source=openai))

JavaScript/JSDoc semantics: less magic, more pain (for some teams)

The Go compiler trims JS support to look more like TypeScript semantics. Closure-era features and a bunch of expando behavior get axed. The big one: constructor functions wired up via prototype + expando properties are explicitly not supported; rewrite to classes. That’s not a “nice to have.” It’s a codebase-wide migration if you’re typechecking serious JS. ([github.com](https://github.com/microsoft/typescript-go/blob/main/CHANGES.md))

The TypeScript team didn’t do a Go rewrite because they were bored. They did it because the JS/Node implementation is boxed in by the same constraints you fight in prod: single-process bottlenecks, GC overhead, and memory ceilings. The beta’s design (fixed worker pools with deterministic partitioning) screams “we want parallelism without turning the checker into nondeterministic soup.” ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

Competitors didn’t cause this directly, but the ecosystem did. Bundlers got fast. Linters got fast. Your slowest step kept being TypeScript. That gap is what forces engineers to do dumb things: skipping typecheck in PRs, slicing monorepos into unnatural shapes, or running transpileOnly everywhere and praying. A compiler that’s actually comfortable on million-LOC repos pays down that debt.

Cynical take: the speed is real, but the migration tax is also real. The beta is basically a forcing function to flush legacy config and module-resolution folklore out of repos. If your build is held together by path aliases and ambient global types, you’re about to learn which parts were load-bearing.

Try the beta CLI (side-by-side):

npm install -D @typescript/native-preview@beta
npx tsgo --version
# then run your usual typecheck command, swapping tsc -> tsgo
npx tsgo -p tsconfig.json --noEmit

Keep TS 6 available (avoid toolchain breakage): use the compatibility package and npm aliasing so tooling that imports typescript doesn’t explode while you experiment. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))

npm install -D typescript@npm:@typescript/typescript6
# run TS6 explicitly when you need it
npx tsc6 -p tsconfig.json --noEmit

Red Flags to watch for in logs:

• RSS spikes / OOM kills after enabling concurrency. If CI is constrained, lower --checkers and/or --builders. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))
• New missing-global-type errors after the types: [] default. Fix by explicitly listing the globals you actually depend on (node/jest/mocha/etc.). ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))
• Import/path alias breakage from baseUrl removal and older resolution modes becoming invalid. Replace with project-root-relative paths + moduleResolution that matches your runtime. ([devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/))
• JSDoc/JS repo churn where Closure/expando patterns used to typecheck. The fix isn’t a flag. It’s code changes. ([github.com](https://github.com/microsoft/typescript-go/blob/main/CHANGES.md))

🛠️ Try These Free Tools

See all free tools →