TypeScript 7 Native: The 10x Faster Compiler That's Changing Everything

What Actually Is TypeScript 7 Native?

Right so here's the situation. TypeScript has been brilliant for web development since Microsoft released it back in 2012, giving us proper static typing for JavaScript and catching errors before they hit production. The problem is that as projects grew larger and larger the TypeScript compiler itself became a bottleneck. It's written in TypeScript which runs on Node.js which is a JavaScript runtime and that means there's effectively an extra software layer between your code and your operating system. For small projects this isn't a big deal but when you're working with massive codebases the compile times can become absolutely painful, we're talking minutes for a full rebuild which kills your productivity when you're trying to iterate quickly.

Microsoft recognised this was becoming a serious problem and in March 2025 Anders Hejlsberg, the lead architect of TypeScript and the brilliant mind behind Turbo Pascal and C# announced Project Corsa, which is the codename for what will eventually become TypeScript 7. The core idea is dead simple really, rewrite the entire TypeScript compiler and toolset in Go which is a statically compiled language that produces native binaries. This removes that JavaScript runtime layer entirely and lets the compiler run directly on your operating system which is fundamentally more efficient. But it's not just about switching languages, they're also rearchitecting how the compiler works to take advantage of shared memory parallelism and concurrency which means it can actually use multiple CPU cores effectively rather than being stuck in single-threaded execution like the current version.

The performance gains they're achieving are honestly quite remarkable. In benchmarks on real-world projects the Sentry codebase went from 133 seconds down to just 16 seconds, that's more than 8x faster. The Visual Studio Code codebase dropped from 89 seconds to under 9 seconds. These aren't carefully constructed demo projects designed to show off the best possible numbers, these are actual production codebases that teams use every single day. Even without incremental build settings TypeScript 7 often sees close to a 10x speedup over the TypeScript 6 compiler on full builds which is absolutely massive when you're working on large projects.

Why This Actually Matters for Your Daily Development

Let's talk about what these performance improvements mean in practice because numbers on a slide are one thing but the real-world impact is what actually matters. When you're working on a large TypeScript project every single compile matters, you make a change and you wait for the compiler to check your types and transpile your code. If that takes 30 seconds instead of 3 seconds you're losing 27 seconds every single time you want to see if your code works. Over the course of a day that adds up to serious time, but more importantly it breaks your flow state. You can't stay in the zone when you're constantly waiting for builds to complete and that cognitive switching cost is actually higher than the raw time loss.

The editor experience improves dramatically as well. Your IDE uses the TypeScript language service to provide all those helpful features like autocomplete, find all references, go to definition, refactoring and inline error checking. With the native implementation these operations become substantially faster, project loading times decrease by around 8x and operations that previously felt sluggish now feel instant. This is particularly noticeable in large codebases where the current TypeScript compiler can struggle to keep up with your typing, you've probably experienced that annoying lag where IntelliSense suggestions appear a second after you've already moved on to the next line.

Memory usage drops significantly too which matters more than you might think. The current TypeScript compiler can be quite memory-hungry especially when working with large projects and that means your machine is using more RAM which can slow down everything else you're running. With the native implementation the memory footprint is substantially reduced which means more headroom for your browser, your terminal, your testing framework and whatever else you've got running whilst you develop. For teams using continuous integration and continuous deployment pipelines this also translates to direct cost savings because you're paying for compute by the minute and if your builds are 10x faster that's 90% less cloud computing time you're paying for.

The parallel compilation capability is particularly clever. The old compiler would churn through projects sequentially even if you had multiple CPU cores sitting idle, but TypeScript 7 can build multiple projects in parallel using shared memory parallelism. This means if you're working in a monorepo with multiple TypeScript projects the compiler can work on several of them simultaneously rather than waiting for each one to finish before starting the next. Combined with the reimplemented incremental builds feature they're getting close to making TypeScript builds feel instantaneous for smaller changes in large projects which is honestly quite impressive.

The Technical Side: What's Actually Changed

If you're interested in the actual implementation details here's what's happening under the hood. The TypeScript team isn't just doing a straightforward port from TypeScript to Go, they're rearchitecting significant portions of the codebase to take advantage of what Go does well. Go is designed for concurrent programming from the ground up with goroutines and channels that make parallel execution natural and efficient, this lets them rewrite parts of the compiler to process different parts of your code simultaneously rather than sequentially which is where a lot of the performance gains come from.

The type checking is very nearly complete at this point. Microsoft has around 20,000 compiler test cases and of those about 6,000 produce at least one error in TypeScript 6. In all but 74 cases TypeScript 7 also produces at least one error and those remaining 74 cases are all either known incomplete work like regular expression syntax checking or intentional changes related to deprecations and default settings updates. This means you can confidently use TypeScript 7 today to type-check your project for errors, the reliability is genuinely there even though it's still technically in preview.

The command-line compiler has reached major parity as well with features like incremental builds, project reference support and build mode all ported over and working. The language service which powers your editor's TypeScript and JavaScript features has most of the functionality that makes up the existing editing experience implemented and working well. They've reimplemented auto-imports, find all references, rename operations and more which were the missing pieces that held a lot of developers back from trying the native previews earlier. Parts of the language service have been rearchitected to improve reliability whilst also leveraging shared memory parallelism which makes everything feel snappier in your editor.

The Breaking Changes You Need to Know About

Now here's the part where we need to talk about what's changing in ways that might affect your existing projects. TypeScript 7 is taking the opportunity to clean up some legacy baggage and make the language stricter by default which means there will be breaking changes. The strict flag will be enabled by default which enforces tighter type safety across the board, this might mean your existing code that compiled fine under TypeScript 5 or 6 will suddenly show errors under TypeScript 7 because it's being more rigorous about type checking.

Support for older environments is shrinking as well, the target es5 compilation option is being removed which means ES2015 becomes the absolute floor for compilation targets. If you're still supporting Internet Explorer 11 or other ancient browsers that need ES5 you're going to have a problem, though honestly if you're still supporting IE11 in 2025 you've probably got bigger problems than TypeScript version compatibility. The team has also stripped down support for some complex and less-used JSDoc patterns which means tags like enum and constructor are no longer recognised if you're using JSDoc for type checking instead of proper TypeScript types.

TypeScript 7 won't support the existing Strada API, that's the old internal API that some tooling might depend on. The new Corsa API is still a work in progress so if you've built tooling that depends on TypeScript's internal APIs you'll need to wait for the new API to stabilise or stick with TypeScript 6 for now. The JavaScript emit pipeline isn't entirely complete yet either so if you absolutely need JavaScript output for older runtimes you might hit some edge cases, though for most developers running tsgo for a build will work fine.

How to Actually Try It Out

Right so if you want to try the native TypeScript compiler today it's actually pretty straightforward. The code is public and available in the TypeScript-go GitHub repository under the same licence as the existing TypeScript codebase. You can use npm to get a preview of the native compiler or if you're using Visual Studio Code there's a preview of the language service available from the Visual Studio Code Marketplace that gets updated every day. Microsoft is also shipping it in Visual Studio 2026 Insiders so if you're on Windows and using Visual Studio you can try it there as well.

To use the native preview in your project you need to edit your package.json file and replace the typescript package with @typescript/native-preview, Visual Studio Code's IntelliSense will help you with this. After that remove your node_modules folder, reinstall your dependencies and reopen your project. Once it's configured you can verify which compiler you're using by opening a TypeScript file and checking the IntelliSense tab of the Output window. Bear in mind this is still an early preview so there might be conflicts if your dependencies bring in the older TypeScript version and not all editor features are supported yet.

Microsoft has been pretty clear that they're taking a dual-track approach for the foreseeable future. TypeScript 6 which is the last JavaScript-based version will bridge the gap between TypeScript 5.9 and TypeScript 7, there's no intention to produce a TypeScript 6.1 release though there may be patch releases for bug fixes. You can think of TypeScript 6 as a bridge release that deprecates features to align with TypeScript 7 whilst maintaining high compatibility in terms of type-checking behaviour. This gives teams time to prepare for the transition without being forced to jump immediately to the native version if they're not ready.

What This Means for the Future

The performance boost from TypeScript 7 creates opportunities that were previously out of reach. Features that seemed too expensive to compute in real-time suddenly become feasible when you've got 10x more performance headroom to work with. The team has mentioned that the native port will be able to provide instant comprehensive error listings across an entire project, support more advanced refactorings and enable deeper insights that were previously too costly. This isn't just about doing the same things faster, it's about enabling entirely new capabilities that couldn't exist with the old compiler architecture.

For AI-powered development tools this is particularly significant. The TypeScript language service provides the foundation that powers AI coding assistants and if that foundation is 10x faster those AI tools can do more sophisticated analysis and provide better suggestions without making your IDE grind to a halt. As AI becomes more integrated into the development workflow having a performant language service becomes increasingly important because you're not just running type checking for yourself anymore, you're running it for the AI too which needs to understand your codebase to provide useful assistance.

Microsoft is targeting early 2026 for the release of both TypeScript 6 and TypeScript 7, they want to keep them closely aligned to ensure a smooth transition path for teams. The goal is to allow developers to choose between the JavaScript-based and native versions based on their needs whilst minimising the friction of moving between them. Some projects will be able to switch to TypeScript 7 immediately upon release whilst others may need to stay on TypeScript 6 due to API dependencies, legacy configurations or other constraints and that's completely fine.

Should You Care About This?

If you're working with TypeScript professionally the answer is absolutely yes you should care about this. The performance improvements aren't marginal gains that only matter for edge cases, they're substantial improvements that will affect your daily development experience. Faster compilation means tighter feedback loops which means you can iterate more quickly and stay in flow state more easily. Better editor performance means less time waiting for IntelliSense and more time actually writing code. Reduced memory usage means your development machine runs more smoothly overall.

For teams the cost savings on CI/CD infrastructure are genuinely significant. If your TypeScript builds are taking 10 minutes and they drop to 1 minute that's 90% less compute time you're paying for, multiply that across hundreds or thousands of builds per day and the savings add up quickly. Beyond the direct cost there's also the developer experience benefit of getting feedback from your CI pipeline 9 minutes sooner which means pull requests get reviewed faster and changes get merged more quickly.

The transition path seems fairly well thought out. Microsoft clearly understands that TypeScript is critical infrastructure for a huge portion of the JavaScript ecosystem and they can't just flip a switch and break everyone's builds. The dual-track approach with TypeScript 6 and 7 running in parallel gives teams time to migrate on their own schedule whilst still getting the performance benefits if they're ready to jump in early. The high degree of compatibility between TypeScript 6 and 7 means most projects should be able to switch without major code changes, though you'll need to deal with the stricter defaults and deprecated features.

The Bottom Line

TypeScript 7's native port represents one of those rare moments where something fundamental changes about how we work. It's not a new feature or a syntax improvement, it's a complete reimplementation that makes everything you're already doing substantially faster and more efficient. The benchmarks are impressive but what really matters is how it feels in daily use and from the reports of teams already using it the experience is genuinely transformative especially for large projects where compile times have been a persistent pain point.

The fact that Microsoft is doing this at all is quite remarkable when you think about it. Rewriting a mature, production-critical compiler from scratch is an enormous undertaking with huge risks. They could have kept iterating on the JavaScript codebase making incremental improvements but they recognised that the architectural limitations meant they'd hit a ceiling eventually. Taking the bold step to port everything to Go and rearchitect for parallelism shows real commitment to making TypeScript the best it can be rather than just maintaining the status quo.

If you're currently working with TypeScript it's worth keeping an eye on the TypeScript 7 previews and testing them out on your projects. The sooner you identify any compatibility issues the sooner you can start planning your migration strategy. And if you're not using TypeScript yet but you've been considering it, knowing that the performance story is about to get dramatically better might tip the scales in its favour. The combination of strong typing, excellent tooling and now genuinely fast compilation makes TypeScript an increasingly compelling choice for serious JavaScript development.

The development community's response has been overwhelmingly positive which is encouraging. When Microsoft first announced the native port there was scepticism about whether they could actually pull it off, compiler rewrites are notoriously difficult and many have failed spectacularly. But the team has been shipping regular updates, hitting their milestones and demonstrating that the new compiler actually works reliably on real projects. The transparency around what's implemented, what's still being worked on and what the breaking changes will be has helped teams plan their transition rather than being caught off guard when 7.0 finally ships.

Looking ahead TypeScript 7 sets a new baseline for what's possible with static type checking in the JavaScript ecosystem. Other tools and languages will likely need to match or exceed these performance characteristics to remain competitive and that's good for everyone. Faster tools mean happier developers, tighter feedback loops and ultimately better software getting shipped faster. Whether you're excited about the technical achievement, the performance gains or just the prospect of not waiting ages for your builds to finish, TypeScript 7 native is shaping up to be one of the most significant developments in the JavaScript world in quite some time.