The TypeScript 7.0 Beta ships a compiler written in Go that produces a standalone native binary, runs without Node.js, and type-checks large codebases roughly ten times faster than its predecessor. That is the headline. But if you trace back through the last few years of TypeScript releases, 7.0 looks less like a sudden leap and more like the final step in a progression that has been unfolding since TypeScript 5.0.
The story is about dependency. Specifically, about TypeScript’s relationship with the JavaScript runtime that has hosted it since 2012, and how that relationship has been quietly unwinding.
TypeScript’s Original Bargain
When TypeScript launched, its value proposition required tight integration with the JavaScript ecosystem. You wrote TypeScript; tsc emitted JavaScript; Node.js or a browser ran that JavaScript. The compiler itself was a Node.js program. This was the whole model. TypeScript existed inside the JavaScript world, not alongside it.
For most of TypeScript’s history, this was fine. The compiler was fast enough. Projects were small enough. And the single-threaded, managed-runtime constraints of running on V8 were invisible when you were checking a 5,000-line codebase.
The seams started showing as monorepos grew. tsc --watch latencies stretched. CI type-checking jobs added minutes to pipelines. The TypeScript team responded well: project references in 3.0, incremental builds with .tsbuildinfo files, smarter change detection. These were genuine improvements, all built within the constraint that the compiler ran on Node.js and could not escape the single-threaded model.
Meanwhile, something interesting was happening outside the TypeScript team’s control.
The Type-Erasure Experiments
Babel added TypeScript stripping support in 2018 via @babel/plugin-transform-typescript. The plugin does not type-check anything. It just removes TypeScript syntax and emits JavaScript. It worked, and a meaningful slice of the ecosystem adopted it because Babel was already in many build pipelines and stripping types this way was faster than running tsc.
SWC did the same thing in Rust. esbuild did it in Go. Vite uses esbuild for development builds. Next.js uses SWC. Suddenly, millions of TypeScript projects were being compiled by tools that treated TypeScript types as comments: present for the editor, irrelevant at runtime.
This created a split. There was TypeScript-the-type-checker (which you ran in CI or pre-commit) and TypeScript-the-syntax (which your bundler stripped and ignored). The two jobs had been conflated since 2012, but the ecosystem quietly separated them.
Deno and Bun both run .ts files natively by stripping types at startup, with no separate compile step. They do not type-check; they just erase. This is fast, ergonomic, and works for the majority of users who trust their editor and CI to catch type errors.
Node.js Joins the Pattern
Node.js 22.6.0 shipped --experimental-strip-types in August 2024, adding native TypeScript execution via type erasure directly in the runtime. You could run a .ts file with node --experimental-strip-types file.ts without any build step. Node.js 23 stabilized this further. The runtime itself no longer treats TypeScript as something that needs to be pre-compiled by an external tool.
The TC39 type annotations proposal, which would add TypeScript-compatible type syntax to JavaScript itself as a comment-like construct that engines ignore, is another data point in the same direction. If types become valid JavaScript syntax that engines strip at parse time, TypeScript’s syntax becomes part of the language standard, and the compiler’s role narrows further to type-checking.
TypeScript’s Own Preparation
The TypeScript team did not sit still while this happened. Two specific features from recent releases read differently in retrospect.
--isolatedDeclarations, added in TypeScript 5.5, requires that exported symbols have explicit type annotations sufficient to generate declaration files without cross-file inference. It is a constraint that makes your code slightly more verbose, but it enables declaration file generation per-file without needing to process the whole project graph. Tools like Bloomberg’s @bloomberg/ts-blank-space and various build pipelines can generate .d.ts files in parallel when isolatedDeclarations is enforced. This is exactly the kind of workload decomposition that becomes important when you want to parallelize type checking across cores, which the Go compiler now does.
--erasableSyntaxOnly, added in TypeScript 5.8, is more pointed. It restricts TypeScript syntax to constructs that can be erased without any type knowledge: no const enum, no namespace declarations, no legacy decorator transforms. The flag is designed specifically for environments where TypeScript is run via type stripping rather than full compilation. It ensures your code is compatible with Node.js’s --experimental-strip-types, Deno, Bun, and any future JavaScript engine that supports the TC39 type annotations proposal natively.
Read together, these features suggest a deliberate direction: TypeScript preparing its own language for a world where the compiler’s emit step is optional or delegated, and type-checking is the compiler’s primary job.
What the Go Binary Resolves
TypeScript 7.0’s Go compiler arrives at the end of this arc. The type-checker is now a native binary that:
- Does not require Node.js to run
- Starts in single-digit milliseconds
- Parallelizes work across cores via goroutines
- Type-checks large codebases in seconds rather than minutes
The emit step (producing JavaScript from TypeScript) was already delegated. esbuild, SWC, Babel, Bun, Deno, and now Node.js itself all handle that. What remained as TypeScript’s exclusive responsibility was the type-checking, and that is what the Go compiler optimizes.
The result is a clean separation: native tools handle the emit, and the Go-based tsc handles correctness verification. You can run tsc --noEmit in CI and get a type-check result in a fraction of the time it previously took, then use whatever bundler fits your pipeline for the actual JavaScript output.
# Type-check only, no emit, using the native Go binary
npx typescript@beta --noEmit
# Node.js handles execution via type stripping
node --experimental-strip-types src/index.tsThe two commands do different things and neither depends on the other finishing first.
What This Changes for Toolchain Design
For anyone building or maintaining tooling around TypeScript, the mental model shift is significant. TypeScript is no longer a monolith that owns the full pipeline from source to JavaScript. It is a type-checker that happens to have an emit mode for legacy compatibility.
This is how tools like ts-morph, code generation pipelines, and schema-from-types libraries should start thinking about their relationship with the compiler. The compiler API surface is being revised in the Go port, and some programmatic use cases that depended on internal TypeScript internals will need to adapt. But the direction is clear: the compiler is a checker, and the ecosystem around it handles the rest.
For developers building Discord bots or backend services in TypeScript today, the practical upshot is simpler: your CI pipeline type-check step goes from being the slow step to being fast. A Dockerfile that previously needed to install Node.js just to run tsc can now pull a small native binary and get the same check in a fraction of the time and image size.
The Beta and What Comes Next
The 7.0 Beta is available now:
npm install --save-dev typescript@betaThe team recommends running both 5.x and 7.0 beta against non-trivial codebases and reporting behavioral differences. Because this is a reimplementation, any divergence from the expected type-checking output is a bug, not a feature. Third-party compiler plugins and tools using the programmatic API should test carefully; the native compiler API is still stabilizing.
The stable release timeline has not been announced. Given the scope of the change, a multi-month beta period is realistic.
What is already clear from the architecture is where TypeScript is going: a language with types that can be stripped for execution, checked natively for correctness, and developed without coupling the type-checker’s performance to the constraints of a garbage-collected scripting runtime. That destination was visible in the ecosystem years before the Go port. The 7.0 Beta is what it looks like when the toolchain catches up.