TypeScript 7 Is About to Land and Your tsc Is Getting 10× Faster — What a Solo Dev Actually Needs to Do

TypeScript 6.0 shipped on March 23 as the final major version built on the JavaScript-based compiler codebase. TypeScript 7, rewritten in Go under the internal codename Project Corsa, is in nightly preview as @typescript/native-preview and close to general availability. The headline claim — "10× faster builds" — is real on large codebases, more modest on small ones, and the daily UX win lives somewhere people aren't talking about enough.

Most of the coverage is aimed at enterprise teams with giant monorepos and slow CI pipelines. I'm a solo developer with a handful of Astro, Next, and Hono projects. Here's the practical version: what to actually do, what to ignore, and why the editor latency improvement is the reason to care more than the build-time one.

What Microsoft Actually Did

The new compiler is a full port of TypeScript to Go. Not a rewrite of the language — the semantics are identical — but a rewrite of the implementation, type checker, language service, and build orchestration. The new binary is tsgo. It ships alongside tsc during the transition and will eventually replace it.

The performance story comes from several places at once. Go's native compilation is straightforwardly faster than running TypeScript's original implementation in a V8 isolate. Memory usage drops significantly because Go's garbage collector is well-suited to the compiler's working-set pattern. The language service (the thing your editor talks to for intellisense) sees the biggest user-visible gains because it runs continuously during your coding session.

The pitch is "10× faster." Microsoft's own benchmarks on large codebases hit that number. On a small Astro project it's closer to 2–3× for a full build. The more interesting number is tail latency in the editor. The old TypeScript language service had noticeable stalls during large refactors, auto-imports, and cross-file rename operations. The new one doesn't. That's the part you feel every hour.

What Actually Breaks

Not much for a typical solo project, which is the main reason this upgrade is worth doing.

Deprecated flags get removed. If you're still using --suppressImplicitAnyIndexErrors or any of the other flags that have been warning you for years, you'll need to remove them. Most modern tsconfig.json files don't have these.

A handful of module resolution edge cases. If you're doing anything exotic with paths, baseUrl, or unusual moduleResolution configs, test carefully. The mainstream cases (bundler, nodenext) work identically. The corners have moved slightly.

Some third-party plugins that patched tsc. If your build depends on something like ts-patch or a custom transformer plugin, check whether the plugin supports tsgo yet. Most major ones do or will by GA.

Reporter format differences. Error messages are the same content. Formatting and colors are slightly different. If you're grepping compiler output in CI, watch for this.

That's the whole list. For the average solo builder — an Astro or Next site, a small Hono API, some React Native code — you'll upgrade without touching your code.

How to Try It Tonight

Three commands, one flag, one verification step.

npm install -D @typescript/native-preview

That installs the preview compiler alongside your existing TypeScript. Doesn't replace anything. Your tsc still works. You now have a new binary called tsgo.

npx tsgo --noEmit

Run the new type checker against your project without emitting files. This is a pure verification pass. You're checking that the new compiler agrees with the old compiler about what's valid. Most projects will see identical output. Any differences are the edge cases above.

npx tsgo --noEmit --extendedDiagnostics

Optional but fun: this prints wall-clock timing and memory stats. Compare it to npx tsc --noEmit --extendedDiagnostics. This is where the 10× headline lives, or doesn't, for your specific project. My own Astro blog went from 4.2 seconds to 1.8 seconds. Not 10×, but meaningful — and more importantly, editor responsiveness improved in a way I noticed within an hour.

If those three commands pass without complaints, you're done. Keep tsgo installed as a dev dependency. When TS 7 GAs — probably within a quarter — swap your default.

The CI Pattern Worth Adopting

While TS 7 is in preview, the safe pattern is to run both compilers in CI for a couple of weeks. Add a job that runs tsgo --noEmit in parallel with your normal type-check step. Don't block on tsgo failures yet. Just observe whether it disagrees with tsc on anything. If it doesn't, swap the default when you're ready. If it does, you've found your edge cases early, on your own schedule.

This sounds like enterprise-brained overhead for a solo project. It isn't. It takes 15 minutes to set up. The cost of finding a regression during a stressful deploy is much higher than the cost of catching it in a non-blocking CI job.

# Add to your GitHub Actions workflow
- name: Type check (legacy)
  run: npx tsc --noEmit

- name: Type check (native, non-blocking)
  run: npx tsgo --noEmit
  continue-on-error: true

Why the Editor Win Is the Real Story

The build time improvement will get the headlines, because it's the easy metric to cite. For a solo developer whose projects build in under a minute on the old compiler, halving the build time is a nice-to-have, not a transformation.

The editor language service is different. That's the thing running continuously while you code. Every auto-import, every hover, every rename, every go-to-definition goes through it. On a project big enough to matter, the old language service had moments of "why is VS Code frozen for four seconds." The new one doesn't. I noticed this within a morning of switching.

If your daily workflow involves long coding sessions in VS Code or JetBrains — which, yes, is most of us — this is the quality-of-life improvement you're actually upgrading for. The build speed is the marketing. The editor responsiveness is the reason.

What to Ignore Until GA

Don't swap your default tsc yet. The preview is stable enough to verify against, not stable enough to trust for production builds.

Don't rebuild your tooling around tsgo specifics. The CLI is designed to be a drop-in replacement. Treat it as one. Resist the urge to write custom wrappers or integrations; they'll be obsolete in three months when GA arrives and the surface is identical to tsc.

Don't worry about the "Go rewrite" angle philosophically. Some developers have strong feelings about TypeScript's implementation language. The semantics of TypeScript are unchanged. The language is the same. You write the same code. The compiler happens to be faster now. That's the whole story.

The Bottom Line

Install @typescript/native-preview, run tsgo --noEmit against your projects tonight, add a non-blocking CI job, and wait for GA. Total time investment: thirty minutes. Editor stalls stop happening. Builds get faster. Memory usage drops. You don't have to change a line of TypeScript.

Microsoft spent multiple years on this. Your part of the work is fifteen minutes of verification and a single npm install. That's the kind of infrastructure win that solo operators should take every time.