TypeScript 7.0 Is Here, and It Finally Uses the Right Tool for the Job
TypeScript 7.0 Is Here, and It Finally Uses the Right Tool for the Job
Or: The compiler finally stopped grading its own homework
The plot
When TypeScript first showed up, it changed how most of us build web apps. That part isn’t controversial. What’s a little more controversial (at least in my head) is how it got built in the first place.
JavaScript was made for the browser. I still believe keeping JS in the browser, and only the browser, would’ve been the cleanest outcome. But that’s not what happened. JS ended up everywhere, servers, CLIs, desktop apps, and people love to tell you “actually, that was the right call all along.” I’m not fully convinced, but that’s a different post.
What I actually want to talk about is TypeScript 7.0, and why it’s a genuinely exciting release, not because TypeScript pulled off something flashy, but because the team finally reached for the right tool for the job.
Why the old setup bugged me
TypeScript is JavaScript with a type system bolted on, and that type system exists because plain JS is dynamically typed. You don’t really know what a variable is at any given point, it can be a string, then a number, then an object, all in the same function, and nothing stops you. Most mature languages don’t hand you that kind of freedom, because it’s very easy to shoot yourself in the foot with it. No enforced types means no real rules. The CPU won’t complain if you convert types sloppily or expect a number where you set a string, but your future self (and your teammates) will.
That’s not really what bugged me though. What bugged me is that until recently, the TypeScript compiler itself (tsc) was written in TypeScript. So TypeScript code was compiling TypeScript code down to JavaScript. If you’ve ever wondered about the philosophical chicken-or-egg question, take a breath, be wise, and just answer “oh, it’s TypeScript.” It’s a bit like grading your own exam. You can be as fair as possible, but it’s still a little odd.
None of that is a reason to hate TypeScript, to be clear. It’s one of the most used languages in web development, for good reason (not because it’s flawless, but because once you filter out the bad tutorials, the fundamentals are genuinely solid).
The turn
On March 11, 2025, Microsoft announced they were porting the TypeScript compiler to Go instead of continuing to self-host it in TypeScript. The whole thing lives in the open at microsoft/typescript-go if you want to poke at the source yourself. That was a big deal at the time, and honestly a great decision. Go compiles to native code, the old self-hosted tsc didn’t, so a native port had real performance headroom to gain.
About a year and a half later, on July 8, 2026, TypeScript 7.0 shipped, the first release built on top of that native Go port.
Here’s the important nuance I got wrong in my head before I actually read the release notes carefully: this is a performance rewrite, not a language rewrite. Your existing .ts files and .d.ts type definitions don’t need to be rewritten. The TypeScript team explicitly designed 7.0 to match TypeScript 6.0’s type-checking and CLI behavior, code that compiled cleanly under 6.0 should compile identically under 7.0. The compiler’s internals changed language (from TS to Go), not the language you write.
What you will run into is some cleanup around long-deprecated options. Things like target: es5 no longer work, and anything you had silenced with ignoreDeprecations will need a real fix instead of a suppression.
What actually changes for you, day to day
Strict mode is still set to true by default. And here’s the funny part: TypeScript has always had a dial for how strict it wants to be with you. Turn it down, and it’s lenient. Turn it up, and it screams. Most of us, myself included, learned JS first, picked up loose habits, and never fully unlearned them just by switching to TS. The only way to actually break the habit is strict mode (or a language that never gave you the option to be sloppy in the first place). TS 7 keeps that default from TS 6, no change here (but somewhere out there, the any cult is still quietly flipping it back to false, they will never learn).
any is still the lazy way out, and it’s still tempting. any tells the compiler “trust me,” and the compiler does, right up until it’s the reason for a 2 a.m. bug. It’s the “when all you have is a hammer, everything looks like a nail” of the type system: whatever the problem is, reach for any and move on. unknown is the better middle ground. The compiler still won’t blindly trust you, so you’re pushed to actually narrow the type (with typeof, instanceof, whatever fits) before you use the value. More friction, but the good kind.
noUncheckedSideEffectImports is on by default too. This one catches side-effect-only imports, the import "./setup" style you’d use for a global CSS file or a config that runs on load, and flags it if the path looks wrong. I don’t lean on this pattern much myself, but if you do (global styles, polyfills, a polyfill is basically when a browser doesn’t support some native method yet, so you write your own version of it and inject it so your code can use it anyway), it’s worth knowing this now gets checked instead of silently failing.
The tooling story isn’t fully there yet, and that’s worth knowing before you upgrade. TS 7.0 doesn’t yet expose a stable public API for the compiler. That matters if your workflow depends on tools that embed TypeScript internally, things like Volar (used by Vue, Astro, Svelte tooling) still rely on TypeScript 6.0 under the hood for now. For plain .ts/.tsx projects, VS Code has a dedicated TS 7 extension, and Visual Studio picks it up automatically per workspace. I couldn’t find anything in the release notes about Zed or Neovim specifically, which matters to me since that’s my daily setup and tsserver slowness is exactly why I’m interested in this release in the first place. If you’re on a lighter editor, this is genuinely a “wait and see” situation, not a “broken” one.
For more on what TypeScript 7 ships with, you could watch Anders Hejlsberg walk through it himself on YouTube.
Where I land
The headline reason this release matters isn’t a new feature or syntax, it’s that the team stopped making the TypeScript compiler grade its own homework and gave the job to a tool built for it. Using the right tool for the right problem is a boring lesson, but it’s the correct one, and it’s nice to see it applied here without any harsh feelings toward the old approach.
I’m holding off on a real verdict until 7.1 lands. What I actually want to test is whether the Go-based architecture trickles down into a faster, less freeze-prone language server for editors like mine. That’s the part that touches my day-to-day the most, and it’s the part the 7.0 notes are honest about not having fully solved yet.
P.S. If you’re still on target: es5, that’s your sign. Nobody needs IE support in 2026.