Should You Upgrade to TypeScript 7 Yet?

Upgrade to TypeScript 7 now if your project is plain TypeScript and already builds cleanly on 6.0. If you depend on typescript-eslint, Vue, Svelte, Astro, MDX or Angular template checking, run 7.0’s tsc alongside 6.0 and wait for 7.1 before switching fully.

The speed numbers are tempting. Then you remember that your lint pipeline, your .vue files and a custom codegen script all import typescript, and a major version bump starts to look risky.

TypeScript 7.0 shipped on July 8, 2026. This article covers what the speedup looks like, which config changes will break your build, which tools can’t use 7.0 yet, and how to run both compilers in one repo. It ends with a verdict for each type of project.

How Much Faster Is TypeScript 7?

TypeScript 7.0 is a port of the TypeScript compiler to Go, and Microsoft says it typically makes full builds 8x to 12x faster than TypeScript 6.0. The team did not redesign the compiler. The Go version mirrors how the original code is organised and how it works, so the two compilers give the same results. The gain comes from running as native code and from type-checking on several threads that share memory.

These are the full-build figures from Microsoft’s TypeScript 7.0 announcement:

Microsoft ran these builds with the default of four type-checker workers (--checkers 4) on large open-source codebases. The announcement does not say what hardware it used. The lowest result, tldraw at 7.7x, falls just under the “8x to 12x” range Microsoft states.

The time TypeScript 7 actually saves depends on how big your codebase is. Working from Microsoft’s figures, vscode saves about 115 seconds per full build and tldraw saves under 10. A small app that already type-checks in two seconds will speed up by a similar ratio but save very little time.

Three smaller changes, one line each:

• --checkers and --builders control parallel type-checking and project-reference builds. The 7.0 release notes call both flags experimental.
• --watch now runs on a Go port of Parcel’s file watcher.
• JS and JSDoc checking was reworked to behave more like .ts analysis. The details are in the typescript-go CHANGES.md.

What Breaks When You Upgrade From TypeScript 5.x or 6.0

Code that has no errors on TypeScript 6.0, with stableTypeOrdering turned on and ignoreDeprecations removed, should give the same output on TypeScript 7.0. Everything that breaks comes from 6.0: 7.0 inherits 6.0’s new defaults, and anything 6.0 marked as deprecated now stops the build. Teams coming straight from 5.x take on both sets of changes at once.

New Defaults

Four TypeScript 7.0 defaults, carried over from 6.0, cause most of the breakage:

• strict is true. Expect new errors in loosely typed code. Well-typed helpers built from TypeScript utility types make the transition easier.
• module defaults to esnext.
• rootDir defaults to ./. If your tsconfig.json sits above src, set rootDir explicitly.
• types defaults to []. List global type packages such as node or jest by name, or set ["*"] to get the old behaviour back.

Four more defaults changed: target now tracks the newest finished ECMAScript edition (one step behind esnext), noUncheckedSideEffectImports is true, libReplacement is false, and stableTypeOrdering is true and can’t be turned off.

Deprecations That Are Now Hard Errors

The TypeScript 7.0 release notes list twelve deprecated options and behaviours that are now hard errors:

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (use nodenext or bundler)
• moduleResolution: classic (use bundler or nodenext)
• module: amd, umd, systemjs, none (use esnext or preserve)
• baseUrl (write paths relative to the project root)
• esModuleInterop or allowSyntheticDefaultImports set to false
• alwaysStrict set to false
• The module keyword in namespace declarations
• asserts on imports (use with)
• /// <reference no-default-lib /> under skipDefaultLibCheck
• File paths passed on the command line when the directory has a tsconfig.json, unless you add --ignoreConfig

outFile is not on that list, but it is gone too. The 6.0 release notes say 6.0 already removed it, and that every option 6.0 deprecated is removed entirely in 7.0. If you still use outFile, move that job to a bundler.

There is also a type-level change: inferring from template literal types no longer splits a character such as an emoji into two halves. You’ll only notice this if you wrote type-level string helpers that relied on the old UTF-16 splitting.

Here is a typical legacy config and the version that works on 7.0:

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

The new version drops target so the default applies, points paths at the project root, and sets rootDir and types explicitly.

Microsoft recommends moving to 6.0 first. Upgrade to 6.0, fix every deprecation warning (the TypeScript 6.0 announcement explains each one), remove ignoreDeprecations, and only then install 7.0.

Which Tools Don’t Work With TypeScript 7 Yet?

Tools that import the TypeScript compiler as a library, and the tools behind Vue, MDX, Astro, Svelte and Angular template checking, don’t work with TypeScript 7.0 yet, because TypeScript 7.0 does not ship a programmatic API. According to Microsoft’s 7.0 announcement, tools that import the compiler as a library, such as typescript-eslint, must keep running on TypeScript 6.0 through the @typescript/typescript6 compatibility package. If your type-aware linting with typescript-eslint setup relies on a peer dependency on typescript, it needs the alias setup described in the next section.

Embedded languages are also affected. Microsoft’s 7.0 announcement says Vue, MDX, Astro and Svelte projects should stay on TypeScript 6.0 for now. Volar and similar tools build TypeScript support into those file formats by calling the compiler directly, and 7.0 has no API for them to call. Angular template type-checking has the same limitation. For Angular, the announcement suggests a split: use 7.0’s tsc from the command line and in CI to catch errors across the whole project quickly, and leave 6.0 in charge of the editor so template checking keeps working.

In VS Code, Microsoft’s dedicated TypeScript 7 extension has two command palette commands, “Disable TypeScript 7 Language Server” and “Enable TypeScript 7 Language Server”, so you can move the editor between 6.0 and 7.0 whenever you need to. If the editor starts misbehaving after the switch, the usual TypeScript debugging workflow in VS Code still applies.

Microsoft plans to add an API back in TypeScript 7.1, though it won’t match the old one. That release is the realistic point for these integrations to move over.

How to Run TypeScript 7 and 6.0 Side by Side

To run both versions in one repo, use npm aliases. Point the typescript package name at the 6.0 compatibility package, and install 7.0 under a different name. Tools that import typescript then load 6.0. The compatibility package gives you the 6.0 API plus a 6.0 command called tsc6.

In a plain npm project, npx tsc then runs 7.0. There is a catch. The compatibility package depends on a full copy of TypeScript 6.0 that declares its own tsc, so two packages compete for that command name. Users have reported that Yarn and Bun can link tsc to 6.0 instead. The typecheck script below calls the 7.0 file directly, so it doesn’t depend on which package wins the tsc name. This is the setup Microsoft describes, shown here with scripts:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheck runs 7.0. typecheck:6 runs 6.0, which is useful for checking that both compilers agree during migration. lint resolves typescript to 6.0 through the alias. To set up the 6.0 alias from the terminal instead, run npm install -D typescript@npm:@typescript/typescript6. If you only do that, you get tsc6 and nothing else, so add the 7.0 alias as well.

Run npx tsc --version to see which compiler a plain tsc calls. Microsoft only documents this setup for npm, so check the result yourself if you use pnpm, Yarn or Bun.

Should You Upgrade? The Verdict by Situation

Whether to upgrade to TypeScript 7 depends on two things: how clean your 6.0 build is, and whether anything in your toolchain imports the compiler.

New project: start on 7.0. If you’re migrating from Flow to TypeScript, aim for 7.0’s defaults from the start so you don’t have to migrate a second time.

Small plain-TS codebase: go to 6.0, fix every deprecation, then switch. The time saved will be small, but you’ll be on the maintained line.

Large monorepo: set up the alias, move CI type-checking to 7.0’s tsc now, and keep linting, codegen and the editor on 6.0 until 7.1 ships its API.

Conclusion

TypeScript 7.0 type-checks your code almost exactly as 6.0 does, only faster. Nearly everything that breaks comes from 6.0’s deprecations or from tools that need a compiler API. Start by getting a clean build on 6.0 with no ignoreDeprecations. After that, either switch completely or add the npm alias and let CI run 7.0’s tsc while your tooling stays on 6.0 until 7.1.

FAQs

Is tsgo or @typescript/native-preview the same thing as TypeScript 7?

Not any more. Before 7.0 shipped, the Go compiler was previewed in the @typescript/native-preview package, and its command was tsgo. The last version of that package is 7.0.0-dev.20260707.2, published the day before the stable release. In TypeScript 7.0 the native compiler lives in the regular typescript package and runs as tsc. Nightly builds now come from typescript@next, so change tsgo to tsc in your CI scripts.

Does TypeScript 7 make Vite, esbuild or SWC builds faster?

No. Vite, esbuild and SWC turn TypeScript into JavaScript by removing the types without checking them, so they never call tsc and their transpile times stay the same. TypeScript 7 speeds up the separate type-check step, usually tsc --noEmit in CI or a pre-commit hook, and the editor language server. If type-checking is not the slowest step in your pipeline, upgrading will not make builds noticeably shorter.

Does ts-node work with TypeScript 7?

Not directly. ts-node compiles files through the TypeScript compiler API, and 7.0 does not ship that API. With the npm alias setup, ts-node's import of typescript resolves to the 6.0 compatibility package, so it keeps running on 6.0 while tsc runs 7.0. For code that uses only erasable syntax, Node.js type stripping in recent versions can run .ts files with no compiler at all, but it does no type-checking.

Can TypeScript 7 still compile to ES5 for older browsers?

No. TypeScript 6.0 raised the lowest supported target to ES2015 and deprecated target es5. In 7.0, target es5 is a hard error. If you still need ES5 output, have tsc emit ES2015 or later and post-process the result with Babel or another compiler. Alternatively, compile the TypeScript source directly with that external tool.