On June 18, 2026, Daniel Rosenwasser posted the release candidate for TypeScript 7.0. The headline is not a new syntax feature or a fancier utility type. It is that the compiler itself has been rewritten in Go, and on my larger React codebases it type-checks roughly ten times faster than the version I shipped last month.
I spent a weekend running it against real projects. Below are the questions I kept asking, answered the way I wish someone had answered them for me.
Wait, TypeScript is written in Go now?
The compiler is. TypeScript has always been a bootstrapped project: the tool that checks your .ts files was itself written in TypeScript and compiled to JavaScript running on Node. Over the past year the team, led by Anders Hejlsberg, ported that codebase to Go under the codename Corsa. The language you write has not changed. The program that reads it has.
Here is Hejlsberg walking through the reasoning when the port was first announced back in March 2025.
Is the 10x number real, or marketing?
It is real, with an asterisk. Microsoft measured type-checking at about 10 times faster than TypeScript 6.0, and my own runs landed in that neighborhood on cold checks of a 200k-line monorepo. Two things drive it: native compiled code with no Node startup tax, and shared-memory parallelism spread across worker threads, which the old single-threaded JavaScript build could never do.
The asterisk: the gain is heaviest on type-checking and full builds. If your day is mostly warm editor feedback on a small app, you will feel it less. The people who will notice most are the ones currently staring at a 90-second tsc --noEmit in CI.
Do I have to rewrite anything?
No. This is the part I found reassuring. The Go version was ported file by file from the original implementation rather than reinvented, so its type-checking logic is structurally identical to 6.0. The same code that passed before should pass now, and the same errors should surface in the same places. That was the whole point of a port instead of a rewrite.
How do I actually try it?
The RC ships as the normal package. The tsc binary inside it is the Go-native compiler, so there is no separate tool to learn.
npm install -D typescript@rc
npx tsc --noEmit
If you want to keep your stable toolchain and just benchmark, install into a scratch branch and time both:
# on your current setup
time npx tsc --noEmit
# after installing typescript@rc
time npx tsc --noEmit
The nightly channel is separate and still publishes under @typescript/native-preview, where the binary keeps the name tsgo. For the RC itself you do not need it.
What about my React project specifically?
Type-checking a component tree is exactly the workload that benefits. A file like this, with inferred props flowing through generics, is precisely where the old compiler spent its time:
type Column<T> = {
key: keyof T;
header: string;
render?: (row: T) => React.ReactNode;
};
function DataTable<T extends { id: string }>({
rows,
columns,
}: {
rows: T[];
columns: Column<T>[];
}) {
return (
<table>
<tbody>
{rows.map((row) => (
<tr key={row.id}>
{columns.map((col) => (
<td key={String(col.key)}>
{col.render ? col.render(row) : String(row[col.key])}
</td>
))}
</tr>
))}
</tbody>
</table>
);
}
Nothing about this code changes. It just gets checked faster, both in CI and in the editor once the language service catches up.
Should I put it in CI today?
For a side project, yes, and I already have. For a team repo, I would run it in a parallel non-blocking CI job first and compare its output against your current tsc for a week. Since the behavior is meant to be identical, any diff in reported errors is a signal worth filing upstream.
A build tool that is ten times faster but 1 percent different in what it accepts is not a win. The bet the team made is that identical behavior matters more than any new feature, and so far my diffs have been empty.
When is the stable release?
Microsoft has said GA is expected roughly a month after the RC, which points at some time in July 2026, though they were careful to call it an estimate rather than a committed date. Visual Studio 2026 has already been enabling the TypeScript 7 beta by default in its Insiders builds, so the tooling side is moving in step.
What this actually changes
The interesting thing is not the speed by itself. It is what stops being a constraint. When a full type-check drops from a coffee break to a few seconds, you start running it on every save, every pre-commit hook, every pull request, without negotiating with yourself about the cost. Fast tools do not just save time. They change which habits are affordable. That is the part of TypeScript 7.0 I will still be thinking about long after the novelty of the number wears off.