TypeScript 7.1 beta ships with a stabilized programmatic API
Microsoft's TypeScript team landed the 7.1 beta today, and for a slice of the frontend world this is the release that finally lets tooling follow the compiler onto the fast, Go-based engine. It's installable right now: npm install -D typescript@beta.
The catch, as there usually is one, is inside the box. Microsoft is careful to call this "a new (and different) API," not a re-skin of the old one. That distinction matters more than you'd think, and it's been keeping third-party tools hostage for over a year.
Here's where we came from. TypeScript 7.0 arrived in July 2026 as a from-scratch rewrite in Go, and it delivered roughly a 10x speedup on type-checking. Microsoft's own benchmarks put vscode's check down from 125.7 seconds to 10.6, with sentry, bluesky, and playwright landing in the 8-9x range. Slack reportedly wiped out 40% of its merge-queue time, Canva trimmed first-error latency from about 58 seconds to under 5, and a Microsoft News Services team estimated saving 400 hours a month.
But 7.0 shipped without a public programmatic API, the interface that tools like Volar, the Svelte language service, Angular's template checker, ts-morph, and typescript-eslint rely on to call into the compiler. So those tools got told to stick with TypeScript 6.0 while the rest of the ecosystem moved on. Microsoft published a compatibility package, @typescript/typescript6, exposing a tsc6 executable so both compilers could run side by side. Still, workflows that embed JavaScript in foreign files like .vue, .svelte, .astro, MDX, and Angular templates were stuck, since tools like Volar need a stable API to wire the compiler in.
Announcing TypeScript 7.1 Beta - TypeScript
Announcing TypeScript 7.1 Beta, bringing a preview API and new features, all while being faster and leaner than TypeScript 7.0.
The API that was missing
Head here to the GitHub repo if you want the full entry-point list, but the shape is clear. 7.1 breaks the compiler into focused entry points: typescript/sync for a synchronous client, typescript/async as the Promise-based twin, typescript/fs for request-scoped filesystems, and typescript/ast plus its is and factory submodules for syntax trees.
The whole thing is built around two ideas that reflect how the Go compiler actually behaves in production: resource lifecycle and snapshots.
API and Program instances eat memory and do bookkeeping across the Go and JavaScript runtimes. Leave them to the garbage collector and you get leaks on the Go side. So you have to dispose them explicitly: api.close(), program.dispose(), apiSymbol.dispose, or bind them with JavaScript's newer using keyword for automatic cleanup.
Snapshots are the more interesting part for anything that isn't a one-off compile. You can create a fresh one with api.createSnapshot, or derive a new state from an old one through snapshot.update(...), which sidesteps recomputing everything. And you can still query the prior snapshot after an update, which is the tell-tale sign of immutable, versioned state. Microsoft also ships virtual filesystem APIs so tools can work over in-memory files and even emit to strings without touching disk.
Now for the part that actually unlocks Vue, Svelte, Astro, and MDX. Content mappers are a new plugin point that lets the compiler include file types it otherwise ignores. A mapper takes a foreign file's text, turns it into valid TypeScript, and hands back mappings so editors can give you diagnostics, autocomplete, go-to-definition, and rename inside embedded regions.
You register them in tsconfig.json under a new contentMappers key, pointing at a package and a list of extensions. Caveat: because these are effectively arbitrary executables the compiler dispatches, you have to run tsc with a --runExternalCode flag to opt in. In VS Code it just works, but only with workspace trust and a toggle under js/ts.contentMappers.enabled.
Microsoft says Volar's model is now "a first-class citizen," having prototyped mappers for Astro, CSS Modules, Ember, MDX, Svelte, and Vue, plus an example HTML mapper for script tags. That's a clean way out of the workaround territory that left these ecosystems stranded.
But keep in mind that a beta landing today doesn't mean your tools work today. Volar, the Svelte and Angular teams, and the maintainers of ts-jest, ts-morph, and typescript-eslint each have to ship their own compatibility updates. Watch those projects' release notes over the next few weeks, not just TypeScript's own calendar.
The 2026 target and the rest
Beyond the API, 7.1 rounds out a handful of modern ECMAScript proposals. Import attributes now work in ambient modules, so you can tie a declare module to a specific with clause. Import without the right attribute is now an error, and the type follows from the attribute. Microsoft recommends libraries not ship these declarations in published packages, to avoid polluting global scope.
Source-phase imports, import source SomeModule, land too. They return a parsed-but-not-linked module, which is mostly useful for WebAssembly since the result drops straight into WebAssembly.instantiate. Dynamic source imports work as well, via import.source(...).
A stable es2026 target pulls in new 2026 declarations like Math.sumPrecise(), JSON.rawJSON(), Error.isError(), and Uint8Array base64 and hex helpers. The esnext lib adds Promise.allKeyed, Iterator.zip, and Iterator.chunks, still in flight.
The beta also carries some changes worth a read before you upgrade. The DOM lib declarations shift, which can quietly affect type-checking. And distributive type parameters get stricter: in a conditional type that distributes over a union, T in each branch is now a more specific subtype and no longer assumed to share constraints. Some code that used to compile will now error, per PR #64237.
The performance batch is the other headline. Following 7.0's 10x jump, 7.1 packs dozens of pull requests aimed at memory pressure and build speed. Microsoft benchmarked five large codebases on four type-checker threads with --noEmit, and the standout is mui-docs, which shaved nearly half its memory, dropping from 8,093 MiB to 4,079 MiB. Not every codebase rewards the changes equally though. mui-docs also ran about 1.9x faster, while bluesky and vscode crept up by a hair.
The community thread told its own story. Anticipation for a stable API dominated, with ts-morph and typescript-eslint explicitly blocked since 7.0. A user asked whether the compiler's deep-instantiation caps should come back up as tooling grows more complex, and Ryan Cavanaugh pushed back, warning that raising the limits would just make the compiler fast only to go slow again. Jake Bailey pointed to content mappers as the escape hatch: push the heavy type inference into a static .d.ts generation step. There were memory-leak reports too, some folks citing 30 to 40 GB of RAM from the language server. The team asked for reproducers. Reproducers, not promises. The general read was that 7.1 is "the release that actually matters," enthusiasm cooled by the reality that downstream migrations take time.
The official plan called for a beta on October 6, nudged to around October 20. The RC is set for November 10, and stable ships November 24. Rosenwasser cited a desire for more test time on the new API before it stabilized. The typescript-go milestone sits at about 95%, and analysts frame November 24 as the realistic stable date, with most stacks expected to drop TypeScript 6 around Q2 2027 once tooling has fully migrated.
If you just run tsc on plain files, you likely got your win in 7.0. 7.1 adds incremental speed and a few language features, but nothing forces an immediate upgrade. If you build tooling that drives the compiler, this is your release, and the content mappers especially are what let editor extensions and linters run on the fast native engine. If you lean on Vue, Svelte, Astro, MDX, or Angular templates, test the beta now but don't expect everything to work out of the box.
Head here to the GitHub repo to follow the typescript-go build. The RC lands about a month out, with stable shortly after.
