Before you move a build to TypeScript 7, check it for custom transformers

TypeScript 7 is the same compiler, ported to Go. Microsoft's own figures put a typical full build eight to twelve times faster. The upgrade itself is a version bump in package.json, which is the appealing part. If your build also runs a custom transformer, a plugin that rewrites your code while it compiles, that step stops happening. The build still exits 0.

So my advice is to search the build for a transformer before you switch. If you find one you depend on, stay on TypeScript 6, or move that step out of the compiler. Angular teams have nothing to decide yet. Angular 22 pins TypeScript to the 6.0 line, so the upgrade is not available to them in the first place.

Where a transformer hides in a build

A custom transformer is a JavaScript function the compiler calls while it writes your output. It receives the parsed file and hands back a changed one. Teams use them to strip debug calls, or to generate runtime validators from a type.

tsc has never had a flag for this, so something else always attaches the transformer. There are three usual places to look. One is a plugins entry in tsconfig.json, which is what ts-patch reads. Another is getCustomTransformers in the ts-loader options of a webpack config. The third is a script of your own that calls createProgram and passes transformers to the emit step.

Grep the repo for those three names. If none of them is there, this post isn't about your build.

The same project, two compilers

The demo is one file with two debug() calls in it, plus a transformer that deletes statements which are nothing but such a call. The transformer is wired up the ts-patch way, in tsconfig.json:

"plugins": [{ "transform": "./transformer.cjs" }]

Two compilers then build that project from that one config file: TypeScript 6.0.3 with ts-patch installed, and TypeScript 7.0.2. Both print nothing and both exit 0. The TypeScript 6 output has no debug() call left in it. The TypeScript 7 output has both of them:

// out/ts7/app.js, the whole file as TypeScript 7.0.2 wrote it
function debug(message) {
    console.log('[debug] ' + message);
}
export function largestOrder(orders) {
    debug('largestOrder received ' + orders.length + ' orders');
    let best;
    for (const order of orders) {
        if (best === undefined || order.total > best.total) {
            best = order;
        }
    }
    debug('largestOrder chose ' + (best === undefined ? 'nothing' : best.id));
    return best;
}

Why the compiler says nothing

TypeScript 7.0 shipped without a JavaScript API. Importing the typescript package used to give you the whole compiler. In 7.0 it gives you its version and nothing else, so there's no emit call left for anything to pass a transformer to. A stable API is promised for 7.1, which is still a nightly build.

The config file is the other half of the silence. plugins is documented as a list of language service plugins to run inside the editor. Plain tsc has long accepted that entry and ignored it, and ts-patch patches the compiler so that it reads it anyway. TypeScript 7 is a Go binary with no JavaScript compiler left to patch, so the entry goes back to meaning nothing.

The silence is specific, though. Put an option in the same file that TypeScript 7 has never heard of, and it stops:

tsconfig.unknown-option.json(11,5): error TS5023: Unknown compiler option 'notARealCompilerOption'.

That file still carries the plugins entry. The compiler has nothing to say about that half.

What I would do

Stay on TypeScript 6 while a transformer is doing real work in your build. The speed is worth a great deal, but not an output you can't account for. For an Angular 22 app the question doesn't arise: the framework's TypeScript range is >=6.0.0 <6.1.0, and npm will refuse 7 as a peer conflict unless you force it.

Where I do have a choice, I'd treat the upgrade as a reason to get the transformer out of the compiler. A transformer that only runs because somebody patched tsc is a dependency on that patch, and the move to Go is exactly what took the patch away. A bundler plugin or a separate code-generation step survives a compiler swap. That is more work than waiting for 7.1, and I'd still do it for anything the output depends on.

Whether 7.1 brings the hook back is genuinely open. The ts-loader branch that targets the new API accepts getCustomTransformers and does nothing with it, and its own notes say the option may be dropped if the API never exposes the extension point. Adding a new tsc transformer to a project today is the one thing I'd argue against in a review.

How you find out is worth a thought as well. A build that runs tspc, which is ts-patch's own wrapper around the compiler, crashes on TypeScript 7 rather than going quiet, and that's the kinder failure. The quiet one is the bump itself: npm install typescript@7.0.2 replaces the patched package, prints nothing unusual, and your next build is green with the transformation gone.

The demo builds that same project with both compilers and asserts all of it: github.com/gdhami-net/typescript-7-transformers-demo.