Skip to content
The Stacklumen platform is in private alphaSee the products

TypeScript 7.1 beta: the native compiler gets faster again

The TypeScript 7.1 beta is up to 1.9 times faster than 7.0 on the team's benchmarks and adds content mappers for framework files. Test it on a branch before the RC, due in about a month.

A chart of build time: TypeScript 6.0 as the baseline, 7.0 about ten times faster, and the 7.1 beta up to 1.9 times faster again, beside the words “TypeScript 7.1, faster again.”
On this page
  1. How TypeScript got here
  2. Faster checks, less memory
  3. Content mappers bring framework files to the compiler
  4. The new API and the language changes
  5. Two changes that can break a build
  6. What to do now
  7. Sources

The TypeScript team released the TypeScript 7.1 beta on 20 October 2026. It makes the native compiler that arrived with 7.0 faster again: 1.2 to 1.9 times faster than 7.0 on the team's benchmarks, with 15.8% to 49.6% less memory. It also adds content mappers, a plugin point that lets tools for Vue, Svelte, Astro and other file formats show those files to TypeScript. If you build sites or apps in TypeScript, test it now: a release candidate is expected in about a month, with the final release shortly after.

How TypeScript got here

TypeScript 6.0, released on 23 March 2026, was intended as the last release on the original JavaScript codebase. TypeScript 7.0 followed on 8 July: a native port written in Go, with shared-memory multithreading, which the team describes as often about 10 times faster than 6.0. It also turned 6.0's deprecations into errors, so settings such as target: es5 no longer work.

7.0 shipped without a programmatic API, so linters and other tools that drive the compiler stayed on 6.0, which a compatibility package, @typescript/typescript6, installs beside 7.0. Type checking for Vue, Astro, Svelte and MDX files, and for Angular templates, stayed on 6.0 for the same reason. The 7.1 beta starts to close both gaps.

Faster checks, less memory

The beta brings dozens of optimisations for memory and build speed. On five real-world codebases, checked with the default four type-checker threads and --noEmit, all five got faster and used less memory.

The largest gain was on a component library's documentation site: a full check fell from 22.2 seconds to 11.9, and memory from 8,093 MiB to 4,079 MiB. The smallest was on a social app's codebase: 4.48 seconds to 3.89. Your own numbers will differ; on CI machines with little memory, watch the memory figure.

Content mappers bring framework files to the compiler

For website teams, the most useful addition is content mappers, a plugin point for file formats that embed JavaScript or TypeScript. A mapper is listed in tsconfig.json under contentMappers, with the package to load, the file extensions it handles and any options. It turns a file such as a .vue component into a virtual version TypeScript can read, with regions that map back to the original, so errors land in the right place in the file you wrote.

Mappers have been prototyped or implemented for Astro, CSS Modules, Ember, MDX, Svelte and Vue, but the package in the team's own Vue example is not on npm yet, so check your framework's status before planning around one. A mapper is code that TypeScript runs: tsc runs mappers only with --runExternalCode, and an editor runs them only once the workspace is trusted and content mapper permission is granted. Use that flag only with packages you trust.

The new API and the language changes

7.1 brings the programmatic API that 7.0 lacked. It is new and different from the old one, with entry points such as typescript/sync, typescript/async and typescript/ast, and the team is still refining it and asking for feedback. Most teams will meet it through the linters and build plugins that adopt it.

The language and library changes are smaller:

  • Import attributes in ambient module declarations. A declaration such as declare module "*" with { type: "css" } types every import that carries that attribute, and TypeScript reports one that leaves it off. Libraries should not publish these declarations; projects write their own.
  • Source phase imports. import source is a proposed ECMAScript feature, useful today mainly for WebAssembly: a source import can go straight to WebAssembly.instantiate.
  • es2026 is a stable target. --target es2026 and --lib es2026 cover methods such as Error.isError(), Math.sumPrecise() and Uint8Array.prototype.toBase64().
  • New esnext methods. --lib esnext adds proposed methods such as Promise.allKeyed and Iterator.zip.

Two changes that can break a build

  • DOM types. The DOM types generated for lib.d.ts have changed, which may surface new errors in code that uses browser APIs.
  • Distributive conditional types. Inside a conditional type's branches, a distributed type parameter is now treated as its own, more specific type. Code that relied on the old behaviour can fail with "Type 'B' does not satisfy the constraint 'A'". The team suggests removing a constraint that was not needed, or adding a conditional check that satisfies it.

What to do now

  1. On a branch, install the beta with npm install -D typescript@beta and run your usual checks, such as tsc --noEmit. Compare time and memory with 7.0 on the same machine.
  2. Fix what the two breaking changes surface, and report regressions while 7.1 is still a beta.
  3. If you build with Astro, Svelte or Vue, follow your framework's content mapper work.
  4. If you maintain a tool that drives the compiler, try the new API and send feedback before the release candidate.
  5. If you are on 6.0 or earlier, move to 7.0 first, clearing 6.0's deprecation warnings on the way. Keep production builds on a stable release until 7.1 is final.
  6. If a codebase reads a Terminal site's CMS, the TypeScript module the Content API generates for it uses no DOM types, so 7.1's DOM changes do not touch it.

Sources

New posts, in your inbox.

Product updates and field notes from Stacklumen, sent when a new post goes up. No spam, and one click to leave.