---
title: "TypeScript 7.1 Beta: up to 1.9x faster type checking. Try it now?"
description: "According to Microsoft's numbers, TypeScript 7.1 Beta finishes type checking 1.2 to 1.9 times faster than 7.0 and with less memory. Try it now on a separate branch, because it has a change that can break the build."
url: https://ihsanalapsi.dev/articles/typescript-7-1-beta
lang: en
date: 2026-10-21
updated: 2026-10-25
tags: ["Developer tools", "Web development"]
author: Ihsan Alapsi (إحسان العبسي)
---
# TypeScript 7.1 Beta: up to 1.9x faster type checking. Try it now?
Microsoft's TypeScript team released 7.1 Beta on October 20, 2026, after 7.0 came out on July 8. If type checking in your CI is slow or runs out of memory, this release is for you. Before you upgrade, know that a stricter type check can stop the build, and the speedup changes from project to project, so you need to measure it yourself.
## How much faster is TypeScript 7.1 Beta than 7.0?
Based on Microsoft's measurements on five projects, TypeScript 7.1 Beta finishes type checking 1.2 to 1.9 times faster than 7.0 and uses 15.8% to 49.6% less memory. The runs used 4 type-checking threads, the default setting, with `--noEmit`.
Here are the numbers as the team published them in the [beta announcement](https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/), from 7.0 to 7.1 Beta:
| Project | Time on 7.0 | Time on 7.1 Beta | Speedup | Time saved |
| ------------- | ----------- | ---------------- | ------- | ---------- |
| bluesky | 4.48 s | 3.89 s | 1.2x | 13.2% |
| mui-docs | 22.2 s | 11.9 s | 1.9x | 46.6% |
| sentry | 19.6 s | 15.1 s | 1.3x | 22.8% |
| t3code-server | 26.5 s | 19.1 s | 1.4x | 28.2% |
| vscode | 21.6 s | 17.7 s | 1.2x | 17.7% |
And here is memory in the same runs:
| Project | Memory on 7.0 (MiB) | Memory on 7.1 Beta (MiB) | Reduction |
| ------------- | ------------------- | ------------------------ | --------- |
| bluesky | 2,017 | 1,698 | 15.8% |
| mui-docs | 8,093 | 4,079 | 49.6% |
| sentry | 6,587 | 5,216 | 20.8% |
| t3code-server | 6,894 | 5,197 | 24.6% |
| vscode | 8,387 | 6,943 | 17.2% |
These are their numbers, on these specific projects, and the announcement doesn't say what hardware they measured on. Behind the gap is a long list of compiler improvements (49 items in the announcement) meant to cut memory use and speed up builds. Your project may see a smaller or a bigger gap, so the number that matters is the one you measure yourself (last section).
## What change could break your build?
The most important change to test now is a stricter check for distributive conditional types. Code that passed on 7.0 can raise a TS2344 error on 7.1, and that is what stops the build in CI.
A conditional type picks between two types based on a condition, like `T extends X ? A : B`. If `T` turns out to be a union, the compiler splits it and applies the condition to each member on its own. That is called a distributive conditional type.
The problem is that inside each branch, `T` is one piece of the union, not the whole union, and older versions treated it as the original `T`. So a constraint like `B extends A` passed even when it wasn't true for every piece. This example is from Microsoft's announcement:
```typescript
type Show = `${B} extends ${A}`;
type Issue =
A extends B ?
never :
Show;
// TypeScript 7.0: no error, UhOh becomes "0 extends 1"
type UhOh = Issue<0 | 1, 0>;
```
In `Issue<0 | 1, 0>` the condition is distributed over 0 and 1. When `A` becomes 1 and `B` stays 0, the constraint `B extends A` becomes `0 extends 1`, which is wrong. On 7.0.2 this code passes with no error, and on 7.1.0-beta you get this:
```
error TS2344: Type 'B' does not satisfy the constraint 'A'.
'B' is only assignable to the non-distributed 'A', but 'A' has been distributed here.
```
The change landed in [PR 64237](https://github.com/microsoft/TypeScript/pull/64237), and Microsoft suggests two fixes: remove the constraint if you don't need it, or add a condition that checks it inside the branch. Here is the second fix:
```typescript
type Fixed =
A extends B ?
never :
B extends A ? Show : never;
```
This version passes on 7.0.2 and on 7.1.0-beta with no errors, so you can merge the fix into your main branch before you upgrade. To find these errors in your project, search for the message text:
```bash
npx tsc --noEmit | grep -B1 "has been distributed here"
```
There is another source of new errors in this upgrade: the DOM types in lib.d.ts were updated, and they can raise errors in code that touches the browser. The details are in the [lib.d.ts updates issue for 7.1](https://github.com/microsoft/TypeScript/issues/63702).
## What's new in TypeScript 7.1?
Besides speed, TypeScript 7.1 adds `--target es2026`, import attributes in ambient modules, `import source`, and a new programmatic API. Import attributes, `import source` and the API change nothing in your project unless you use them.
But if you don't set `target` in `tsconfig.json`, the default is now `es2026` in 7.1 Beta, while in 7.0.2 it was `es2025` (per `tsc --help --all` in both versions). So code that uses ES2026 functions passes on the beta and raises TS2339 and TS2550 errors on 7.0.2.
### `--target es2026`
`es2026` is now a stable option for `--target` and `--lib`. The main thing it brings is types for the functions that became stable in ECMAScript 2026, like `Math.sumPrecise()`, `Error.isError()`, `Map.prototype.getOrInsert()`, `Uint8Array.fromBase64()` and `Array.fromAsync()`.
On 7.0.2 the same option raises a TS6046 error, so don't put it in `tsconfig.json` before the whole team has moved. And the types don't add the functions to the runtime: make sure the browsers or the Node.js version you run on support them.
### Import attributes in ambient modules
Import attributes are the `with { type: "..." }` part after an import, and they tell the browser or the bundler how to read the file. In 7.1 you can declare a file's type by its attribute instead of its extension, and the compiler raises an error if you forget the attribute:
```typescript
declare module "*" with { type: "text" } {
const content: string;
export default content;
}
```
These declarations don't come with TypeScript, and Microsoft advises libraries not to put them in their packages: each project writes its own. Their syntax doesn't parse on 7.0.2, so they only help once everyone working on the project has upgraded.
### `import source`
`import source` is an ECMAScript proposal that gives you the module after it is parsed and before it runs. Its clearest use today is WebAssembly files: it gives you a `WebAssembly.Module` that you pass straight to `WebAssembly.instantiate`. It needs `--module` set to `esnext`, `nodenext` or `preserve`, plus `esnext` in `--lib` or `--target`. And according to Microsoft, many runtimes and tools don't support it yet for JavaScript files.
### The programmatic API
TypeScript 7.1 has a new API for building tools on top of the compiler's analysis, split into entry points like `typescript/sync`, `typescript/async`, `typescript/fs` and `typescript/ast`. The API and the program must be closed after use (with `using`, or by hand with `close()` and `dispose()`), because the 7.x compiler is written in Go and holds memory for them on its side that the JavaScript garbage collector doesn't clean up.
The announcement calls it a preview API, and the team is still working on it with partner teams and wants feedback. If you're building a tool on top of it, treat it as a preview until the final release.
## Why do content mappers need `--runExternalCode`?
A content mapper is a plugin that turns a file like `.vue` or `.svelte` into a TypeScript version the compiler understands, and maps errors back to their place in the original file. Because it's an outside program that the compiler runs, `tsc` only runs it with `--runExternalCode`.
Before 7.1, the Volar project gave editors type checking for these files, but command-line checking tools couldn't use its approach. Now the idea Volar was built on is part of the compiler itself, and Microsoft says there are experimental or ready content mappers for Astro, Vue, Svelte, MDX, Ember and CSS Modules.
You register a content mapper in `tsconfig.json` by file extension:
```json
{
"contentMappers": [
{
"package": "@vue/content-mapper",
"extensions": [".vue"]
}
]
}
```
The package name is from Microsoft's example, and according to the announcement it isn't published on npm yet. After that, you run the check with `tsc --runExternalCode`.
Microsoft itself says a content mapper is, in practice, any program the compiler runs, and that's why the option is explicit. So with this option, `tsc` runs code from an npm package on your machine and in CI.
The [PR that added the feature](https://github.com/microsoft/typescript-go/pull/4712) explains that the package itself decides how its program runs. So:
- Put `--runExternalCode` only in the project that has content mappers, not in a shared script for every project.
- Pin the package version in the lockfile, and review it like any package that runs at build time.
- In VS Code they only run in a trusted workspace and after you approve their permissions, and you can turn them all off with the `js/ts.contentMappers.enabled` setting.
## What is tsrs, and does it replace TypeScript 7.1?
tsrs is an experimental TypeScript compiler written in Rust, announced by Cloudflare on October 20, 2026. It's still for testing, so it can't replace TypeScript in a live project yet.
According to [Cloudflare's post](https://blog.cloudflare.com/typescript-rust-port/), Cloudflare and VoidZero are working on it with Max Schwenk from Owner.com, in coordination with the TypeScript team. The project is part of the Oxc tools, and the goal is not a fork of the language. The [project's README](https://github.com/oxc-project/tsrs) thanks Max Schwenk for the port to Rust and Owner.com for funding the early work, and says: "Not affiliated with or endorsed by Microsoft".
On the numbers, Cloudflare says tsrs is up to 8 times faster than TypeScript 7.0 and uses about 70% less memory, with the same number of workers. That's an early measurement by the company itself, not a result checked by a third party.
The same post says 7.1 Beta is up to 2.5 times faster than 7.0. But its chart measured a nightly build (`7.1.0-dev.20261019.1`) against `7.0.2`, not the published beta, with the options `--noEmit --incremental false --pretty false --checkers 4`. And the top number on both sides comes from the same project, mui-docs: 1.9x at Microsoft and 2.58x at Cloudflare. So the same project gets a different number when the version and the way you measure change.
As of October 21, the latest tsrs release on npm starts with `0.18.0`, and the README lists known differences in error ordering, and says `--init` and `--showConfig` aren't supported. If you're curious, try it on a copy of your project, and keep your real build on Microsoft's TypeScript.
## Who is TypeScript 7.1 for, and what should you do now?
TypeScript 7.1 matters most for large projects on 7.0 with slow checks, for Vue, Svelte and Astro projects that stayed on 6.0, and for tools that read the compiler programmatically. If you're still on 5.x, your first step is 6.0, not the beta.
| Your situation | What changes for you | What to do now |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| On 7.0, and type checking in CI is slow or runs out of memory | Faster checks and less memory per Microsoft's numbers, and new TS2344 errors may show up | Try the beta on a branch and measure (last section) |
| Still on 5.x or 6.0 | Options Microsoft marked deprecated in 6.0, like `target: es5`, `downlevelIteration` and `baseUrl`, stop the build on 7.0 and 7.1 Beta | Upgrade to 6.0 first and clean up `tsconfig.json`, then stable 7.0 |
| A Vue, Svelte, Astro or MDX project | The 7.0 announcement said it should stay on 6.0, and 7.1 brings content mappers | Keep production on 6.0, and try your framework's content mapper on a branch when it's out |
| A tool that reads the compiler programmatically, like typescript-eslint | 7.0 came out without an API, and 7.1 has a preview API | Keep the tool on 6.0 next to 7 until it announces 7.1 support |
Moving from 5.x is the longest step, because 7.0 follows 6.0's defaults: `strict` is on by default, `types` is `[]`, and `rootDir` is `./`. According to the [7.0 announcement](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/), the release is built to behave like 6.0 in type checking and on the command line. That's why Microsoft advises going through 6.0 first, and expects `rootDir` and `types` to surprise people the most. On 7.0.2 and 7.1.0-beta, a `"baseUrl": "."` line in `tsconfig.json` gives you this:
```
error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
Use '"paths": {"*": ["./*"]}' instead.
```
And if you have a tool that still needs 6.0, Microsoft published the `@typescript/typescript6` package with 7.0 so you can run both versions side by side, and recommends installing it with npm aliases in `package.json`:
```json
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
```
This way `npx tsc` runs 7.0, and tools that import `typescript` get 6.0. The 7.1 Beta announcement doesn't mention typescript-eslint, so check the tool's release notes before you remove 6.0.
## How do you try the beta on your project now?
Make a separate branch, measure type checking on 7.0 before you upgrade, then install `typescript@beta` and measure the same way. That way you see the real difference on your project and catch the new errors before they reach your main branch.
1. Measure on your current version, and save the `Total time` and `Memory used` numbers:
```bash
npx tsc --noEmit --extendedDiagnostics | grep -E "Total time|Memory used"
```
2. Make a branch and install the beta:
```bash
git switch -c try/typescript-7.1-beta
npm install -D typescript@beta
npx tsc --version
```
The last command prints `Version 7.1.0-beta`.
3. Run the same measuring command on the same machine. Repeat each run 3 times and take the median, because a single run can mislead you.
4. Fix the distributive conditional type and DOM errors (second section), and make sure each fix also passes on 7.0.2, because the default `target` isn't the same in the two versions (third section). Merge the fixes that pass on both into your main branch now.
5. Repeat the measurement in CI on the branch, because the CI machine is usually different from yours. And if your build runs out of memory, that's where the difference shows.
Keep production on 7.0 for now. According to Microsoft, the RC comes about a month after the beta, and the final release shortly after that. As of October 21, 2026, the stable version on [npm](https://www.npmjs.com/package/typescript) is `7.0.2`.
If you have a coding agent like Claude Code do the upgrade, ask it to work only on the branch and to give you the measurements on both versions before it fixes any error. The [AI skills section](/products/c/ai-skills) has Claude Code skills for your daily work.
If you want a repo to practice the steps on before your work code, Secure Clinic API Suite and WhatsApp Number Extractor on the [projects page](/work) are written in TypeScript, with the full code on GitHub.
And for someone new on the team who is learning TypeScript from scratch, [Developer Roadmap 2026](/products/roadmap-2026) places it as the language of the web in the front-end track, with a 90-day plan.
How long does `tsc --noEmit` take for you now, and how long on the beta?
## FAQ
**Is TypeScript 7.1 Beta ready for production?**
No. It's a beta, and as of October 21, 2026 the stable version on npm is 7.0.2. Try the beta on a branch and in CI, and keep production on 7.0 until the final release is out.
**When will the final TypeScript 7.1 release come out?**
Microsoft hasn't set a date. The beta announcement says the RC comes in about a month, and the final release shortly after it.
**Do I need to change tsconfig.json to try the beta?**
No. Installing it with npm install -D typescript@beta is enough, and contentMappers are optional. But two things change without you touching anything: if you don't set target, the default is now es2026 instead of es2025, and the change to distributive conditional types can raise new errors.
**Do content mappers run on their own in VS Code?**
Yes, under two conditions: the workspace must be trusted, and you must approve the content mapper's permissions. You can also turn them all off with the js/ts.contentMappers.enabled setting.
**Is tsrs faster than Microsoft's TypeScript?**
According to Cloudflare, yes, up to 8 times faster than 7.0 with the same number of workers, but that's an early measurement by the company itself. tsrs is still experimental and its latest npm release is from the 0.18 series, so measure it on your project before you trust any number.