Skip to content

TypeScript 7 and Your Bundler: What Actually Has to Change

Does TypeScript 7 break your bundler? Mostly no. The split that matters is whether a tool calls tsc as a process or embeds its API. Here is the list.

· · 6 min read
Close view of interlocking black metal gears in an old machine

Quick Take

Bundlers never compiled TypeScript, they stripped types. So the TypeScript 7 migration lands on your type-checker, not your build. The tools that do break are the ones embedding the compiler API, and TypeScript 7.0 does not ship a stable one.

Your bundler almost certainly does not compile TypeScript, and it never did. It strips the types out and hands plain JavaScript to the rest of the pipeline. That one fact decides most of what the TypeScript 7 migration means for your build chain, and it is why the answer for the majority of projects is "nothing changes in the build, quite a lot changes in the type-check."

Bottom line: Vite, esbuild and SWC are unaffected because they never touch the compiler. The tools at risk are the ones that load the compiler as a library, which today means ts-loader on webpack and @rollup/plugin-typescript. The reason is in the release notes: TypeScript 7.0 does not yet expose a stable programmatic API.

If you want the whole upgrade end to end, the TypeScript 7 migration guide covers it. This piece is only about the build chain.

Why does the compiler API decide everything here?

There are two ways a build tool can involve TypeScript, and the difference is architectural rather than cosmetic.

A tool can call tsc as a process. It runs the binary, waits, reads the exit code. Vite does this for its type-check script. Your CI does it. Nothing about the internals of the compiler matters, so a rewrite of those internals in Go changes nothing for the caller.

Or a tool can embed the compiler as a library, importing it into its own process and driving it through function calls. That is how ts-loader type-checks inside a webpack build and how @rollup/plugin-typescript emits declarations. It is faster and better integrated, and it binds the tool to an API surface rather than to a command line.

The TypeScript 7.0 announcement is explicit about which of those two is a problem: "TypeScript 7.0 does not yet expose a stable programmatic API", with a new and different API expected in 7.1. So the callers are fine and the embedders are waiting.

A single black metal gear resting on a dark machine surface
Photo by Mike Hindle on Unsplash

How do you tell which camp your tool is in?

You do not have to read any source. Ask npm:

npm info ts-loader peerDependencies
npm info esbuild-loader peerDependencies

At the time of writing that returns:

ts-loader:      { webpack: '^4.0.0 || ^5.0.0', typescript: '*', 'loader-utils': '*' }
esbuild-loader: { webpack: '^4.40.0 || ^5.0.0' }

A typescript peer dependency is the tell. The package expects you to install the compiler alongside it so it can import it, which means it is an embedder. esbuild-loader does not ask for one, because it has no use for the compiler: esbuild carries its own TypeScript parser and simply deletes the annotations.

Run the same command against @rollup/plugin-typescript and you get typescript: '>=3.7.0'. Same camp. Run it against @swc/core and you get nothing TypeScript-related at all.

That is a two-second test you can run against any tool in your chain, including ones nobody has written a migration note for yet.

What has to change in tsconfig regardless of bundler?

This part is not optional and it is where most upgrades actually stall. TypeScript 7 removed options that TypeScript 6 only warned about:

  • moduleResolution: node and node10 are gone. Use bundler or nodenext.
  • moduleResolution: classic is gone, with the same two replacements.
  • module: amd, umd, systemjs and none are gone. Use esnext or preserve and let the bundler do the module work.
  • target: es5 is gone, and downlevelIteration with it.

For a bundled application moduleResolution: "bundler" and module: "esnext" is the combination you want, and it is what Vite and webpack both expect anyway. If any of those removed values are in your config today, the compiler stops rather than warns.

Which bundler needs what?

ToolEmbeds the compiler?What to doStatus
ViteNoSet moduleResolution: "bundler", keep type-checking in a separate tsc --noEmit scriptWorks
esbuildNo, own parserNothing in the build. Keep tsc --noEmit in CI for actual checkingWorks
SWCNo, own parserSame as esbuildWorks
webpack + esbuild-loaderNoNothingWorks
webpack + ts-loaderYesCheck the loader's release notes before upgrading; this is the one to test firstVerify
Rollup + @rollup/plugin-typescriptYesSame caution. If you only need transpilation, swap to an esbuild or SWC pluginVerify
tsupPartlyBundling is esbuild and unaffected; dts generation goes through the compilerVerify
TurbopackNoTranspiles without type-checking, same model as SWCWorks

The honest shape of that table is that most of it says "works", and the exceptions all sit in the same column.

A bright pink industrial pipe running along a metal support structure
Photo by Martin Adams on Unsplash

A correction worth making

Our own migration guide previously told webpack users to "bump ts-loader to v10+". Check npm and that version does not exist: the latest published release is in the 9.x line. If you followed that advice and found nothing to install, the advice was wrong, not your registry. The guide has been corrected.

The useful instruction is the general one instead of a version number: for a tool that embeds the compiler, read its own release notes for native-compiler support before you upgrade TypeScript, because the package's readiness is a fact about that package and not something you can infer from the TypeScript version.

What about type-checking speed, which is the actual reason to do this?

Worth keeping in view, because the build chain is the part that does not change and the type-check is the part that gets dramatically better. Microsoft's announcement puts the native compiler at "typically yield speedups between 8x and 12x on full builds".

That lands entirely on tsc --noEmit, which is the step your bundler never did for you. If your CI type-check is the slow job in the pipeline, that job is the whole payoff, and none of it depends on touching your bundler config.

Where to go next

If your stack is React on Vite, the React migration checklist sequences the whole thing including Vitest and ESLint. If you are on Vue, Svelte or Astro, stop here and read TypeScript 7 framework support first, because those toolchains embed the compiler for exactly the reason described above and the answer is different. For pipeline configuration, TypeScript 7 in CI/CD covers the GitHub Actions side.

One closing opinion you are free to disagree with: the embed-versus-call split is a better mental model for build tooling than the usual bundler-by-bundler comparison, and it will keep being useful long after this particular migration is finished. Any tool that imports another tool's internals inherits that tool's release schedule. That is worth knowing before you choose the loader, not after.

Frequently Asked Questions

Does TypeScript 7 break Vite?
No. Vite strips types with esbuild and never asks the TypeScript compiler to do anything, so the upgrade does not touch your build at all. What it touches is the separate type-check step you run with tsc, plus two tsconfig options: moduleResolution must be bundler or nodenext, because node and node10 were removed, and module must not be amd, umd or systemjs.
Which build tools actually break on TypeScript 7?
The ones that embed the compiler as a library rather than calling it as a process. ts-loader for webpack and @rollup/plugin-typescript both declare typescript as a peer dependency, which is the tell: they import the compiler API, and TypeScript 7.0 ships without a stable programmatic API. esbuild-loader declares no such peer dependency, because it does not use the compiler at all.
How do I tell whether my bundler embeds the TypeScript compiler?
Run npm info <package> peerDependencies and look for typescript in the output. A tool that lists it is loading the compiler into its own process and depends on an API surface that TypeScript 7.0 has not stabilised. A tool that does not list it either has its own TypeScript parser, like esbuild and SWC, or shells out to the tsc binary, which works normally.
Do I still need tsc if my bundler handles TypeScript?
Yes, and more than before. esbuild, SWC and Vite are fast precisely because they delete type annotations without checking them, so nothing in your build verifies your types. The tsc --noEmit step in CI is the only thing that does, and TypeScript 7 is where that step got roughly 8x to 12x faster, which is the whole reason to upgrade.