{"id":4886,"date":"2025-05-22T07:04:21","date_gmt":"2025-05-22T15:04:21","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=4886"},"modified":"2025-12-11T23:10:30","modified_gmt":"2025-12-12T07:10:30","slug":"announcing-typescript-native-previews","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-native-previews\/","title":{"rendered":"Announcing TypeScript Native Previews"},"content":{"rendered":"

This past March we unveiled our efforts to port the TypeScript compiler and toolset to native code<\/a>.\nThis port has achieved a 10x speed-up on most projects – not just by using a natively-compiled language (Go), but also through using shared memory parallelism and concurrency where we can benefit.\nSince then, we have made several strides towards running on large complex real-world projects.<\/p>\n

Today, we are excited to announce broad availability of TypeScript Native Previews.\nAs of today, you will be able to use npm to get a preview of the native TypeScript compiler.\nAdditionally, you’ll be able to use a preview version of our editor functionality for VS Code through the Visual Studio Marketplace<\/a>.<\/p>\n

To get the compiler over npm, you can run the following command in your project:<\/p>\n

npm install -D @typescript\/native-preview\r\n<\/code><\/pre>\n
This package provides an executable called tsgo<\/code>.\nThis executable runs similarly to tsc<\/code>, the existing executable that the typescript<\/code> package makes available:<\/p>\n
npx tsgo --project .\/src\/tsconfig.json\r\n<\/code><\/pre>\n
Eventually we will rename tsgo<\/code> to tsc<\/code> and move it to the typescript<\/code> package.\nFor now, it lives separately for easier testing.\nThe new executable is still a work in progress, but is suitable to type-check and build many real-world projects.<\/p>\n
But we know that a command-line compiler is only half the story.\nWe’ve heard teams are eager to see what the new editing experience is like too, and so you can now install the new “TypeScript (Native Preview)” extension in Visual Studio Code.\nYou can easily install it off of the VS Code Extension Marketplace<\/a>.<\/p>\n
Because the extension is still in early stages of development, it defers to the built-in TypeScript extension in VS Code.\nFor that reason, the extension will need to be enabled even after installation.\nYou can do this by opening VS Code’s command palette<\/a> and running the command “TypeScript Native Preview: Enable (Experimental)”.<\/p>\n
\"TypeScript<\/p>\n
Alternatively, you can toggle this in your settings UI by configuring “TypeScript > Experimental: Use Tsgo”<\/p>\n
\""Use<\/p>\n
or by adding the following line to your JSON settings:<\/p>\n
\"typescript.experimental.useTsgo\": true,\r\n<\/code><\/pre>\n
Updates, Release Cadence, and Roadmap<\/h2>\n
These previews will eventually become TypeScript 7 and will be published nightly so that you can easily try the latest developments on the TypeScript native port effort.\nIf you use the VS Code extension, you should get automatic updates by default.\nIf for whatever reason you find any sort of disruption, we encourage you to file an issue<\/a> and temporarily disable the new language service with the command “TypeScript Native Preview: Disable”:<\/p>\n
\"TypeScript<\/p>\n
or by configuring any of the settings mentioned above.<\/p>\n
Keep in mind, these native previews are missing lots of functionality that stable versions of TypeScript have today.\nThat includes command-line functionality like --build<\/code> (though individual projects can still be built with tsgo<\/code>), --declaration<\/code> emit, and certain downlevel emit targets.\nSimilarly, editor functionality like auto-imports, find-all-references, and rename are still pending implementation.\nBut we encourage developers to check back frequently, as we’ll be hard at work on these features!<\/p>\n
What’s New?<\/h2>\n
Since our initial announcement, we have made some notable strides in type-checking support, testability, editor support, and APIs.\nWe would also love to give a brief update of what we’ve accomplished, plus what’s on the horizon.<\/p>\n
Note that while the native preview will eventually be called TypeScript 7, we’ve casually been referring to it as “Project Corsa” in the meantime.\nWe’ve also been more explicit in referring to the codebase that makes up TypeScript 5.8 as our current JS-based codebase, or “Strada”.\nSo in our updates, you’ll see us differentiate the native and stable versions of TypeScript as “Corsa” (TS7) and “Strada” (TS 5.8).<\/p>\n
Fuller Type-Checking Support<\/h3>\n
The majority of the type-checker has been ported at this time.\nThat is to say, most projects should see the same errors apart from those affected by some intentional changes (e.g. this change to the ordering of types<\/a>) and some stale definitions in lib.d.ts<\/code>.\nIf you see any divergences and differences, we encourage you to file an issue to let us know<\/a>.<\/p>\n
It is worth calling out support for two major type-checking features that have been added since our initial announcement: JSX and JavaScript+JSDoc.<\/p>\n
JSX Checking Support<\/h3>\n
When developers first got access to the TypeScript native port<\/a>, we had to temper expectations.\nWhile type-checking was pretty far along, some constructs were still not fully checked yet.\nFor many developers, the most notable omission was JSX.\nWhile Corsa was able to parse JSX, it would mostly just pass over JSX expressions when type-checking and note that JSX was not-yet supported.<\/p>\n
Since then, we’ve actually added type-checking support for JSX and we can get a better sense of how fast a real JSX project can be built.\nAs an example codebase, we looked at the codebase for Sentry<\/a>.\nIf you run TypeScript 5.8 from the repository root with --extendedDiagnostics --noEmit<\/code>, you’ll get something like the following:<\/p>\n
$ tsc -p . --noEmit --extendedDiagnostics\r\nFiles:                         9306\r\nLines of Library:             43159\r\nLines of Definitions:        352182\r\nLines of TypeScript:        1113969\r\nLines of JavaScript:           1106\r\nLines of JSON:                  304\r\nLines of Other:                   0\r\nIdentifiers:                1956007\r\nSymbols:                    3563371\r\nTypes:                       999619\r\nInstantiations:             3675199\r\nMemory used:               3356832K\r\nAssignability cache size:    944737\r\nIdentity cache size:          43226\r\nSubtype cache size:          110171\r\nStrict subtype cache size:   430338\r\nI\/O Read time:                1.40s\r\nParse time:                   3.48s\r\nResolveModule time:           1.88s\r\nResolveTypeReference time:    0.02s\r\nResolveLibrary time:          0.01s\r\nProgram time:                 7.78s\r\nBind time:                    1.77s\r\nCheck time:                  63.26s\r\nprintTime time:               0.00s\r\nEmit time:                    0.00s\r\nTotal time:                  72.81s\r\n<\/code><\/pre>\n
That’s over a minute to type-check this codebase!\nLet’s see how the native port fares with some minimal changes.<\/p>\n
$ tsgo -p . --noEmit --extendedDiagnostics\r\n...\r\nFiles:              9292\r\nLines:           1508361\r\nIdentifiers:     1954236\r\nSymbols:         5011565\r\nTypes:           1689528\r\nInstantiations:  6524885\r\nMemory used:    3892267K\r\nMemory allocs:  61043466\r\nParse time:       0.712s\r\nBind time:        0.133s\r\nCheck time:       5.882s\r\nEmit time:        0.012s\r\nTotal time:       6.761s\r\n<\/code><\/pre>\n
There are some discrepancies in results, but Corsa brings build times down from over a minute to just under 7 seconds on the same machine.\nYour results may vary, but in general we’ve seen consistent speed-ups of over 10x on this specific example.\nYou can try introducing an error in existing JSX code and tsgo<\/code> will catch it.<\/p>\n
You can see more over at our PR to port JSX type-checking<\/a>, plus some follow-on support for tslib and JSX factory imports<\/a>.<\/p>\n
JavaScript Checking<\/h3>\n
TypeScript supports parsing and type-checking JavaScript files<\/a>.\nBecause valid JavaScript\/ECMAScript doesn’t support type-specific syntax like annotations or interface<\/code> and type<\/code> declarations, TypeScript looks at JSDoc comments in JS source code for type analysis.<\/p>\n
The native previews of TypeScript now also support type-checking JS files.\nIn developing JS type-checking for Corsa, we revisited our early decisions in our implementation.\nJavaScript support was built up in a very organic way and, in turn, analyzed very specific patterns that may no longer be (or may never have been) in widespread use.\nIn order to simplify the new codebase, JavaScript support has been rewritten rather than ported.\nAs a result, there may be some constructs that may need to be rewritten, or to use a more idiomatic\/modern JS style.<\/p>\n
If this causes difficulties for your project, we are open to feedback on the issue tracker<\/a>.<\/p>\n
Editor Support & LSP Progress<\/h3>\n
When we released the Corsa codebase, it included a very rudimentary LSP-based language server.\nWhile most tangible development has been on the compiler itself, we have been iterating on multiple fronts to port our editor functionality in this new system.\nBecause the Strada codebase communicates with editors via the TSServer format that predates LSP, we are not aiming to do a perfect 1:1 port between the codebases.\nThis means that porting code often requires more manual porting and has required a bit more up-front thought in how we generate type definitions that conform to LSP.\nGathering errors\/diagnostics, go-to-definition, and hover work in very early stages.<\/p>\n
Most recently, we have hit another milestone: we have enabled completions!\nWhile auto-imports and other features around completions are not fully ported, this may be enough for many teams in large codebases.\nGoing forward, our priorities are in porting over our existing language server test suite, along with enabling find-all-references, rename, and signature help.<\/p>\n
API Progress<\/h3>\n
A big challenge as part of this port will be continuity with API consumers of TypeScript.\nWe have the initial foundation of an API layer that can be leveraged over standard I\/O.\nThis work means that API consumers can communicate with a TypeScript process through IPC regardless of the consuming language.\nSince we know that many API consumers will be writing TypeScript and JavaScript code, we also have JavaScript-based clients for interacting with the API.<\/p>\n
Because so much TypeScript API usage today is synchronous, we wanted to make it possible to communicate with this process in a synchronous way.\nNode.js unfortunately doesn’t provide an easy way to communicate synchronously with a child process, so we developed a native Node.js module in Rust (which should make lots of people happy) called libsyncrpc<\/a>.<\/p>\n
We are still in the early days of API design here, but we are open to thoughts and feedback on the matter.\nMore details about the current API server are available here<\/a>.<\/p>\n
Known and Notable Differences<\/h2>\n
As we’ve mentioned, the Corsa compiler and language service may still have some differences from Strada.\nThere are some differences that you may hit early on in trying out tsgo<\/code> and the Native Preview VS Code extension.<\/p>\n
Some of those come from eventual TypeScript 6.0 deprecations<\/a>, like node<\/code>\/node10<\/code> resolution (in favor of node16<\/code>, nodenext<\/code>, and bundler<\/code>).\nIf you use --moduleResolution node<\/code> or --module commonjs<\/code>, you may see some errors like:<\/p>\n
Cannot find module 'blah' or its corresponding type declarations.\r\nModule '\"module\"' has no exported member 'Thing'.\r\n<\/code><\/pre>\n
You will get consistent errors if you switch your tsconfig.json<\/code> settings to use<\/p>\n
{\r\n    \"compilerOptions\": {\r\n        \/\/ ...\r\n        \"module\": \"preserve\",\r\n        \"moduleResolution\": \"bundler\",\r\n    }\r\n}\r\n<\/code><\/pre>\n
or<\/p>\n
{\r\n    \"compilerOptions\": {\r\n        \/\/ ...\r\n        \"module\": \"nodenext\"\r\n    }\r\n}\r\n<\/code><\/pre>\n
These can be manually fixed depending on your configuration, though often you can remove the imports and leverage auto-imports to do “the right thing”.<\/p>\n
Beyond deprecations, downlevel emit to older targets is limited, and JSX emit only works as far as preserving what you wrote.\nDeclaration emit is currently not supported either.\n--build<\/code> mode and language service functionality around project references is still not available, though project dependencies can be built through tsc<\/code>, and the native preview language service can often leverage generated .d.ts<\/code> files.<\/p>\n
What’s Next?<\/h2>\n
By later this year, we will aim to have a more complete version of our compiler with major features like --build<\/code>, along with most language service features for editors.<\/p>\n
But we don’t expect you to wait that long!\nAs TypeScript Native Previews are published nightly, we’ll aim to provide periodic updates on major notable developments.\nSo give the native previews a shot!<\/p>\n
Happy Hacking!<\/p>\n
– Daniel Rosenwasser and the TypeScript Team<\/p>\n","protected":false},"excerpt":{"rendered":"
This past March we unveiled our efforts to port the TypeScript compiler and toolset to native code. This port has achieved a 10x speed-up on most projects – not just by using a natively-compiled language (Go), but also through using shared memory parallelism and concurrency where we can benefit. Since then, we have made several […]<\/p>\n","protected":false},"author":381,"featured_media":1797,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4886","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"
This past March we unveiled our efforts to port the TypeScript compiler and toolset to native code. This port has achieved a 10x speed-up on most projects – not just by using a natively-compiled language (Go), but also through using shared memory parallelism and concurrency where we can benefit. Since then, we have made several […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4886","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/users\/381"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/comments?post=4886"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4886\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media\/1797"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media?parent=4886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=4886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=4886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}