December 2nd, 2025

0 reactions

Principal Product Manager

Earlier this year, the TypeScript team announced that we’ve been porting the compiler and language service to native code to take advantage of better raw performance, memory usage, and parallelism. This effort (codenamed “Project Corsa”, and soon “TypeScript 7.0”) has been a significant undertaking, but we’ve made big strides in the past few months. We’re excited to give some updates on where we are, and show you how “real” the new TypeScript toolset is today.

We also have news about our upcoming roadmap, and how we’re prioritizing work on TypeScript 7.0 to drive our port to completion.

Editor Support and Language Service

For a lot of developers, a project rewrite might feel entirely theoretical until it’s finally released. That’s not the case here.

TypeScript’s native previews are fast, stable, and easy to use today – including in your editor.

TypeScript’s language service (the thing that powers your editor’s TypeScript and JavaScript features) is also a core part of the native port effort, and is easy to try out. You can grab the latest version from the Visual Studio Code Marketplace which gets updated every day.

Our team is still porting features and fixing minor bugs, but most of what really makes the existing TypeScript editing experience is there and working well.

That includes:

• Code Completions (including auto-imports!)
• Go-to-Definition
• Go-to-Type-Definition
• Go-to-Implementation
• Find-All-References
• Rename
• Quick Info/Hover Tooltips
• Signature Help
• Formatting
• Selection Ranges
• Code Lenses
• Call Hierarchy
• Document Symbols
• Quick Fixes for Missing Imports

You might notice a few things that stand out since our last major update – auto-imports, find-all-references, rename, and more. We know that these features were the missing pieces that held a lot of developers back from trying out the native previews. We’re happy to say that these are now reimplemented and ready for day-to-day use! These operations now work in any TypeScript or JavaScript codebase – including those with project references.

We’ve also rearchitected parts of our language service to improve reliability while also leveraging shared-memory parallelism. While some teams reported the original experience was a bit “crashy” at times, they often put up with it because of the speed improvements. The new architecture is more robust, and should be able to handle codebases, both big and small, without issues.

While there is certainly more to port and polish, your team will likely find that trying out TypeScript’s native previews is worth it. You can expect faster load times, less memory usage, and a more snappy/responsive editor on the whole.

If you’re ever unhappy with the experience, our extension makes it easy to toggle between VS Code’s built-in TypeScript experience and the new one. We really encourage you and your team to try out the native preview extension for VS Code today!

Compiler

The TypeScript compiler has also made significant progress in the native port. Just like our VS Code extension, we have been publishing nightly preview builds of the new compiler under the package name @typescript/native-preview. You can install it via npm like so:

# local dev dependency
npm install -D @typescript/native-preview

# global install
npm install -g @typescript/native-preview

This package provides a tsgo command that works similarly to the existing tsc command. The two can be run side-by-side.

A frequent question we get is whether it’s “safe” to use TypeScript 7 to validate a build; in other words, does it reliably find the same errors that TypeScript 5.9 does?

The answer is a resounding yes. TypeScript 7’s type-checking is very nearly complete. For context, we have around 20,000 compiler test cases, of which about 6,000 produce at least one error in TypeScript 6.0. In all but 74 cases, TypeScript 7 also produces at least one error. Of those remaining 74 cases, all are known incomplete work (e.g. regular expression syntax checking or isolatedDeclarations errors) or are related to known intentional changes (deprecations, default settings changes, etc.). You can confidently use TypeScript 7 today to type-check your project for errors.

Beyond single-pass/single-project type checking, the command-line compiler has reached major parity as well. Features like --incremental, project reference support, and --build mode are also now all ported over and working! This means most projects can now try the native preview with minimal changes.

# Running tsc in --build mode...
tsc -b some.tsconfig.json --extendedDiagnostics

# Running the *new compiler* in --build mode...
tsgo -b some.tsconfig.json --extendedDiagnostics

Not only are these features now available, they should be dramatically faster than the existing versions implemented in TypeScript 5.9 and older (a.k.a. the “Strada codebase”). As we’ve described previously, this comes in part from native code performance, but also from the use of shared-memory parallelism. More specifically what this means is that not only can TypeScript now do fast multi-threaded builds on single projects; it can now build up multiple projects in parallel as well! Combined with our reimplementation of --incremental, we’re close to making TypeScript builds feel instantaneous for smaller changes in large projects.

Just as a reminder, even without --incremental, TypeScript 7 often sees close to a 10x speedup over the 6.0 compiler on full builds!

Project	tsc (6.0)	tsgo (7.0)	Delta	Speedup Factor
sentry	133.08s	16.25s	116.84s	8.19x
vscode	89.11s	8.74s	80.37s	10.2x
typeorm	15.80s	1.06s	14.20s	9.88x
playwright	9.30s	1.24s	8.07s	7.51x

Expected Differences from TypeScript 5.9

There are some caveats to using the new compiler that we want to call out. Many of these are point-in-time issues that we plan to resolve before the final 7.0 release, but some are driven more by long-term decisions to make the default TypeScript experience better. The promise of TypeScript 7.0 means that we will need to heavily shift our focus to the new codebase to close existing gaps and put the new toolchain in the hands of more developers. But let’s first dive in and cover some of the current changes and limitations.

Deprecation Compatibility

TypeScript 7.0 will remove behaviors and flags that we plan to deprecate in TypeScript 6.0. Right now, you can see the list of upcoming deprecations in 6.0 on our issue tracker. Some prominent examples include:

• –strict will be enabled by default
• –target will default to the latest stable ECMAScript target (e.g. es2025)
• –target es5 will be removed, with es2015 being the lowest-supported target
• –baseUrl will be removed
• –moduleResolution node10 (a.k.a. node) will be removed in favor of bundler and nodenext
• rootDir defaults to the current directory, and using outDir either requires an explicit rootDir or for top-level source files to be in the same directory as the tsconfig.json

This is not comprehensive, so check out the issue tracker for the current state of things. If your project relies on any of these deprecated behaviors, you may need to make some changes to your codebase or tsconfig.json to ensure compatibility with TypeScript 7.0.

Our team has been experimenting with a tool called ts5to6 to help update your tsconfig.json automatically. The tool uses heuristics on extends and references to help update other projects in your codebase. Currently it can only update the baseUrl and rootDir settings, but more may be added in the future.

npx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig-file-here.json
npx @andrewbranch/ts5to6 --fixRootDir your-tsconfig-file-here.json

Emit, --watch, and API

Even with 6.0-readiness, there are some circumstances in which the new compiler can’t immediately be swapped in.

For one, the JavaScript emit pipeline is not entirely complete. If you don’t need JavaScript emit from TypeScript (e.g. if you use Babel, esbuild, or something else), or if you are targeting modern browsers/runtimes, running tsgo for your build will work just fine. But if you rely on the TypeScript to target older runtimes, our support for downlevel compilation realistically only goes as far back the es2021 target, and with no support for compiling decorators. We plan to address this with full --target support going back to es2015, but that work is still ongoing.

Another issue is that our new --watch mode may be less-efficient than the existing TypeScript compiler in some scenarios. In some cases you can find other solutions like running nodemon and tsgo with the --incremental flag.

Finally, Corsa/TypeScript 7.0 will not support the existing Strada API. The Corsa API is still a work in progress, and no stable tooling integration exists for it. That means any tools like linters, formatters, or IDE extensions that rely on the Strada API will not work with Corsa.

The workaround for some of these issues may be to have the typescript and @typescript/native-preview packages installed side-by-side, and use the ≤6.0 API for tooling that needs it, with tsgo for type-checking.

JavaScript Checking and JSDoc Compatibility

Another thing that we want to call out is that our JavaScript type-checking support (partly powered by JSDoc annotations) has been rewritten from the ground up. In an effort to simplify our internals, we have stripped down some of our support for complex and some less-used patterns that we previously recognized and analyzed. For example, TypeScript 7.0 does not recognize the @enum and @constructor tags. We also dropped some “relaxed” type-checking rules in JavaScript, such as interpreting:

• Object as any,
• String as string,
• Foo as typeof Foo when the latter would have been valid in a TypeScript file,
• all any, unknown, and undefined-typed parameters as optional

and more. Some of these are being reviewed and documented here, though the list may need to be updated.

This means that some JavaScript codebases may see more errors than they did before, and may need to be updated to work well with the new compiler. On the flip side, we believe that the new implementation is more robust and maintainable, and aligns TypeScript’s JSDoc support with its own type syntax.

If you feel like something should be working or is missing from our JavaScript type-checking support, we encourage you to file an issue on our GitHub repository.

Focusing on the Future

When we set out to rewrite TypeScript last year, there were a lot of uncertainties. Would the community be excited? How long would it take for the codebase to stabilize? How quickly could teams adopt this new toolset? What degree of compatibility would we be able to deliver?

On all fronts, we’ve been very pleasantly surprised. We’ve been able to implement a type-checker with extremely high compatibility. As a result, projects both inside and outside Microsoft report that they’ve been able to easily use the native compiler with minimal effort. Stability is going well, and we’re on track to finish most language service features by the end of the year. Many teams are already using Corsa for day-to-day work without any blocking issues.

With 6.0 around the corner, we have to consider what happens next in the JavaScript codebase. Our initial plan was to continue work in the 6.0 line “until TypeScript 7+ reaches sufficient maturity and adoption”. We know there is still remaining work to do to unblock more developers (e.g. more work on the API surface), and closing down development on the Strada line – our JavaScript-based compiler – is the best way for us to get those blockers removed sooner rather than later. To help us get these done as soon as possible, we’re taking a few steps in the Strada project.

TypeScript 6.0 is the Last JavaScript-Based Release

TypeScript 6.0 will be our last release based on the existing TypeScript/JavaScript codebase. In other words, we do not intend to release a TypeScript 6.1, though we may have patch releases (e.g. 6.0.1, 6.0.2) under rarer circumstances.

You can think of TypeScript 6.0 as a “bridge” release between TypeScript 5.9 line and 7.0. 6.0 will deprecate features to align with 7.0, and will be highly compatible in terms of type-checking behavior.

Most codebases which need editor-side Strada-specific functionality (e.g. language service plugins) should be able to use 6.0 for editor functionality, and 7.0 for fast command-line builds without much trouble. The inverse is also true: developers can use 7.0 for a faster experience in their editor, and 6.0 for command-line tooling that relies on the TypeScript 6.0 API.

Additional servicing after TypeScript 6.0 is released will be in the form of patch releases, and will only be issued in the case of:

• security issues,
• high-severity regressions (i.e. new and serious bugs that were not present in 5.9),
• high-severity fixes related to 6.0/7.0 compatibility.

As with previous releases, patch releases will be infrequent, and only issued when absolutely necessary.

But as for right now, we want to ensure that TypeScript 6.0 and 7.0 are as compatible as possible. We’ll be holding a very high bar in terms of which open PRs are merged into the 6.0 line. That takes effect today, and it means most developers will have to set expectations for which issues will be addressed in TypeScript 6.0. Additionally, contributors should understand that we are very unlikely to merge pull requests into 6.0, with most of our focus going bringing 7.0 to parity and stability. We want to be transparent on this front so that there is no “wasted” work, and so that our team can avoid complications in porting changes between the two codebases.

Resetting Language Service Issues

While most of the core type-checking code has been ported over without any behavioral differences, the language service is a different story. Given the new architecture, much of the code that powers completions, hover tooltips, navigation, and more, has been heavily rewritten. Additionally, TypeScript 7.0 uses the standard LSP protocol instead of the custom TSServer protocol, so some behavior specific to the TypeScript VS Code Extension may have changed.

As a result, any bugs or suggestions specific to language service behavior are likely not to reproduce in the 7.0 line, or need a “reset” in the conversation.

These issues are very time-consuming to manually verify, so instead we’ll be closing existing issues related to language service behavior. If you run into an issue that was closed under the “7.0 LS Migration” label, please log a new issue after validating that it can be reproduced in the native nightly extension. For functionality that is not yet ported to 7.0, please wait until that functionality is present before raising a new issue.

What’s Next?

When we unveiled our native previews a few months back, we had to manage expectations on the state of the project. We’re now at the point where we can confidently say that the native TypeScript experience is real, stable, and ready for broader use. But we are absolutely still looking for feedback.

So we encourage you to install the VS Code native preview extension, use the @typescript/native-preview compiler package where you can, and try it out in your projects. Let us know what you think, and file issues on our GitHub repository to help us fix up any issues and prioritize what to work on next.

We’re excited about the future of TypeScript, and we can’t wait to get TypeScript 7.0 into your hands!

Happy Hacking!

Category

Author

Principal Product Manager

Daniel Rosenwasser is the product manager of the TypeScript team. He has a passion for programming languages, compilers, and great developer tooling.