The short version
TypeScript 7.1 beta is the release that makes Microsoft’s Go-based compiler usable for the whole toolchain, not just the command-line build: it adds a stable-track programmatic API and a plugin point for Vue, Svelte and Astro files. Teams that held back from TypeScript 7.0 because linters and framework tooling depended on the old JavaScript API now have a dated path, and teams running TypeScript monorepos get a further cut in CI time and memory.
What is new in TypeScript 7.1 beta?
TypeScript 7.0, released in July, moved the compiler from JavaScript to Go and delivered roughly tenfold faster builds, but it shipped without a stable programmatic API. That left a gap: ESLint plugins, bundler loaders and framework language tools that call the compiler from code had to keep running the older JavaScript-based version alongside it. Version 7.1, announced by TypeScript product manager Daniel Rosenwasser, is built to close that gap.
The new API is split into small entry points instead of one monolithic object: synchronous and promise-based compiler clients, filesystem layers, AST types, node type guards and AST factory functions. Resources are disposable and expected to be released with using declarations, and tools can derive new snapshots from previous ones to model incremental edits across projects. Microsoft calls it a preview, so tool authors should expect changes before it settles.
The second headline is content mappers. A mapper registered in tsconfig.json for an extension such as .vue turns a foreign file into a virtual TypeScript view with mappings back to the original, so editors get accurate errors, completions and rename inside embedded code. Because mappers are external executables, the compiler only runs them with an explicit --runExternalCode flag. The language side adds a stable es2026 target and library, typed import attributes in ambient module declarations and source phase imports, which let code load a WebAssembly module before it runs.
How much faster is TypeScript 7.1?
Microsoft measured type-checking with --noEmit and four checker threads against TypeScript 7.0 on five open-source projects. The gains come from changes such as import affinity balancing, type mapper compaction, inline caching and AST restructuring.
| Project | Check time, 7.0 → 7.1 | Memory, 7.0 → 7.1 |
|---|---|---|
| mui-docs | 22.2s → 11.9s (1.9x) | 8,093 → 4,079 MiB (−49.6%) |
| t3code-server | 26.5s → 19.1s (1.4x) | 6,894 → 5,197 MiB (−24.6%) |
| sentry | 19.6s → 15.1s (1.3x) | 6,587 → 5,216 MiB (−20.8%) |
| vscode | 21.6s → 17.7s (1.2x) | 8,387 → 6,943 MiB (−17.2%) |
| bluesky | 4.48s → 3.89s (1.2x) | 2,017 → 1,698 MiB (−15.8%) |
The beta also carries breaking changes worth testing early: stricter checks when conditional types distribute over unions, and DOM type updates in lib.d.ts that can surface new errors in browser code. Microsoft expects a release candidate about a month after the beta, with the stable release shortly after.
What is tsrs, and is it a fork?
tsrs is a Rust port of the TypeScript compiler that type-checks code, emits JavaScript and declaration files, and builds to WebAssembly so it can run in a browser or on Cloudflare Workers. It started last month at restaurant software company Owner.com, where engineer Max Schwenk faced a 37,000-file TypeScript backend that, by his account, needed 19 GiB of memory and 80 seconds for a single-threaded check on the Go compiler. According to The New Stack, he had AI coding agents write the port, running more than 20 sub-agents in parallel.
Cloudflare and VoidZero now develop tsrs inside the Oxc Rust toolchain, and they are explicit that it is a port, not a fork: Microsoft’s TypeScript team stays in charge of the language, and any behavior difference is treated as a tsrs bug. The collaboration already runs both ways. Rosenwasser wrote that some of what makes 7.1 faster and leaner came from optimizations discovered in tsrs. The project is experimental (npm install tsrs), still differs in details such as diagnostic ordering, and Cloudflare says memory-safety work around circular types must finish before a stable release.
How should teams read the speed claims?
The numbers are not measured the same way, so they should not be compared directly. Microsoft’s table shows 1.2x to 1.9x gains with four checker threads on public projects. Cloudflare’s post states that 7.1 is “up to 2.5x faster” than 7.0 and that tsrs is “up to 8x faster” with “~70% less memory” at equal worker counts. Each figure is a best case from its own maintainer. The only number that matters for a budget is the one from your repository, on your CI runners, with your project references and checker settings.
What it means for US & EU software teams
The practical news is the API, not the speed. Many teams stayed on TypeScript 6 or ran 6 and 7 side by side because typed linting, Vue or Svelte tooling and custom build plugins could not talk to the native compiler. Once those tools adopt the 7.1 API, a codebase can run one compiler for builds, editors and lint. That removes a duplicated install, a second type-check pass in CI and a class of “works in the editor, fails in the build” bugs. For a product owner, the right move is to put the migration on the roadmap for the quarter after 7.1 goes stable, not to start it on a beta.
Memory is the second budget line. Type-checking a large repository is often what caps how many CI jobs, preview environments or AI coding agents can run in parallel on one machine. A 20% to 50% memory cut on the official compiler means smaller runners or more concurrency at the same cost. That matters most for SaaS teams with large Node.js backends and front ends in one monorepo, where a full check runs on every pull request.
tsrs is worth watching, not adopting. Its WebAssembly build points to type-checking inside sandboxes, browser IDEs and edge runtimes where AI agents write and verify code, and Oxc integration could make type-aware linting much cheaper. But it is a weeks-old, largely AI-written port with known gaps. Using it as a merge gate in a regulated FinTech or HealthTech pipeline before it reaches a stable release would add an unverified link to the build chain. A parallel, non-blocking job that compares its output with the official compiler is the safer way to learn.
What to test now
- Run the beta on a branch. Install
typescript@beta, run your usual check with--noEmitand record time and peak memory against 7.0 or 6.x. - Triage new errors. Look for distributive conditional type errors and DOM type changes; decide which are real bugs and which need small type fixes.
- List tools that call the compiler API. Typed ESLint rules, Vue or Svelte language tools, bundler plugins and codegen scripts are the ones that decide your migration date.
- Check your tool vendors’ plans. Track when each tool supports the 7.1 API or content mappers; plan the cut-over after 7.1 stable.
- Pilot tsrs off the critical path. If you want early data, run it as an informational CI job and compare diagnostics with the official compiler; do not block merges on it.
Frequently asked questions
When was TypeScript 7.1 beta released and what does it add?
Microsoft released TypeScript 7.1 beta on October 20, 2026. It adds a preview programmatic API for the Go-based compiler with modular entry points and snapshots, content mappers for formats such as Vue, Svelte and Astro, a stable es2026 target, typed import attributes in ambient modules and source phase imports, along with speed and memory improvements over 7.0.
Is TypeScript 7.1 faster than TypeScript 7.0?
Yes. On Microsoft’s benchmark projects, with --noEmit and four checker threads, type-checking was 1.2x to 1.9x faster and used 15.8% to 49.6% less memory than TypeScript 7.0. The biggest gain was on mui-docs, where check time fell from 22.2 to 11.9 seconds.
What is tsrs?
tsrs is an experimental Rust port of the TypeScript compiler announced by Cloudflare and VoidZero on October 20, 2026 and developed as part of the Oxc toolchain. It claims up to 8x faster checking and about 70% less memory than TypeScript 7.0 at equal worker counts, and it runs in WebAssembly. Its developers say it is a port that follows Microsoft’s compiler, not a fork.
Should teams use TypeScript 7.1 beta or tsrs in production?
Not yet. The 7.1 API is labelled a preview and the release is a beta, with a release candidate expected about a month later. tsrs is experimental and still has known gaps. Teams should test both on a branch or in a non-blocking CI job and plan production migration after TypeScript 7.1 reaches stable.
Sources
Microsoft TypeScript Blog — Announcing TypeScript 7.1 Beta (October 20, 2026)
Cloudflare Blog — Introducing tsrs: a Port of TypeScript to Rust (October 20, 2026)
The New Stack — “We are not forking TypeScript”: Cloudflare spearheads Rust port written by agents, for agents (October 20, 2026)
InfoQ — Microsoft Releases TypeScript 7.0 with a Native Go Compiler