The Go port of the TypeScript compiler ships as a preview, and its announcement promises full builds eight to twelve times faster. Whether a codebase can adopt it before the release settles depends on whether anything it ships is emitted by tsc. On Giant Context nothing is, and on 22 August the typecheck job across twenty-six packages moved to tsgo, the preview's binary. It went from seven and a half minutes to under five. That is about 35 percent rather than eight times, and the missing multiplier is in the orchestration rather than the engine.

That job runs on every push and twice before every production deploy, so those minutes sit on the critical path of every fix that reaches a customer's website. They are also what made deleting the test cache survivable, because a pipeline that runs cold every time can only afford it once its long jobs are shorter.

The preview publishes as @typescript/native-preview and installs the tsgo binary. The classic compiler stays installed as typescript, because anything that imports the compiler's API still needs it and the preview does not expose one. Three consumers here import it. The code generation in packages/generated rewrites source through ts-morph, a library over the compiler API. The typescript-eslint parser reads it. One code-style test imports the API directly. Those keep 5.9.3. Everything else moves.

The move is one word per package.

baseUrl is a hard error in 7, and it was the one breaking change that touched this codebase. The plan was a hop through TypeScript 6.0 so its deprecation warnings would list every tsconfig still carrying it. grep found fourteen entries in twelve files. I planned a diagnostic tool to find work that grep could find.

Three consumers is a short list, and it is short because there is one language. Until June this backend was TypeScript and Python, and a two-language stack has two type checkers, two sets of pins and two of every migration. One compiler pin now governs every package in the tree, and a compiler swap is one commit instead of a project.

Eight to twelve times is a measurement of the engine on one project in one process. A monorepo typecheck has three costs, and only one of them is the engine. The task runner starts a process per package. The packages either run in parallel against a shared type graph or they run one at a time. And then the compiler runs. Which of the three owns the time decides what a faster compiler buys, and nothing in the announcement can say which one it is in someone else's tree.

Here the runner owned most of it. The runner was turbo, the tool that fans a script out across the packages of a monorepo, and there were twenty-six invocations. Each one was a turbo process starting a pnpm process starting the compiler. That startup was a fixed cost the engine could not touch, and removing the runner from the loop saved more than the engine did.

Turbo had also run the twenty-six three at a time. Three packages checking at once each reload the shared type graph, and on a four-core runner with a 6144MB heap that thrashes memory and finishes later than one process would. The loop that replaced turbo is sequential on purpose. Its header says why:

That is the entire replacement for the runner. The CI job kept the same box, heap and timeout and lost its cache restore step, and the root typecheck script now points at this file.

The result is 35 percent cold, from trading three-way parallelism for single-process speed and dropping twenty-six process startups. The same three costs exist in any monorepo in a different ratio. A tree with five packages and one big one will see something close to the engine number. A tree with fifty small ones is paying for fifty startups and should measure the runner before measuring the compiler, because the runner is the cheaper fix and it may be most of the time.

The preview is a second implementation of the same language, and two implementations disagree on module resolution before they disagree anywhere else. The case here is a package that publishes both an ESM and a CommonJS type entry. The classic compiler dedupes them into one type. The preview resolves them as two unrelated types, and any generic constrained across the pair fails.

Any dependency with an exports map carrying separate import and require type conditions is a candidate, and the three named in the comment below all do. Running the loop above against a tree with the new binary produces the list in one pass, because every file that fails is a file the old compiler passed.

Here the list was three files totalling 294 lines in the shared table layer the console's lists are built on. All three type against Material React Table. A file like that has two answers. Keeping its package on the old compiler and branching the loop gives back some of the time for a slice of the tree. Turning checking off in the file with the condition written down gives back none of the time and all of the coverage. I took the second.

Before this commit there were no @ts-nocheck directives in the repository. There are six now, and 294 lines of them are application code no type checker reads. That number does not appear in the job time and it is the price of the migration. Whichever answer a repository picks, the lines it turned off are the figure to write down next to the minutes it saved, because the minutes are on a dashboard and the lines are not.