Type-checking vs transpilation: why your bundler doesn't catch type errors

Two completely different jobs: checking vs transpiling

tsc does two things: it type-checks (analyses the whole program for type errors) and it emits JavaScript. Bundlers split these apart and keep only the second:

The reason bundlers are 10–100× faster than tsc is exactly that they don’t type-check. Type analysis requires building a graph of the whole program; transpilation just deletes type syntax token-by-token in one file. A type error is invisible to them — it’s just syntax they erase.

isolatedModules: making single-file transpilation safe

If your team uses esbuild or swc for emit, there’s a class of perfectly valid TypeScript that will silently produce wrong JavaScript — not an error, just a broken bundle. isolatedModules is the flag that catches those constructs at edit time instead of at runtime.

Because esbuild/swc/babel compile one file at a time with no knowledge of other files, some TypeScript constructs are unsafe to transpile that way — they need whole-program information. isolatedModules: true makes tsc flag exactly those constructs, so your code is portable to a single-file transpiler:

// with isolatedModules, these error in tsc:

// 1. A type-only re-export that LOOKS like a value re-export:
export { SomeType } from "./types";
//       ^^ TS1205-ish: a single-file compiler can't tell if SomeType is a
//          type (erase the export) or a value (keep it). Fix:
export type { SomeType } from "./types"; // now unambiguous — erase it

// 2. const enum across files — needs the enum's values inlined from another file:
import { Color } from "./enums";
const c = Color.Red; // const enum can't be inlined without cross-file info

isolatedModules doesn’t change emit; it restricts what you may write so that per-file transpilation produces correct output. The two big things it effectively forbids: const enum consumed across files (a single-file compiler can’t inline values it can’t see) and ambiguous type-only re-exports (forcing export type / import type).

The pattern: bundler builds, tsc --noEmit gates

The production setup decouples the two jobs. The bundler produces the artifact fast; tsc --noEmit (often tsc -b --noEmit for monorepos) runs in parallel or in CI purely to check types — it emits nothing, just fails the build if a type is wrong:

// package.json scripts
{
  "scripts": {
    "build": "vite build",            // esbuild transpiles — NO type checking
    "typecheck": "tsc --noEmit",      // the real type gate — emits nothing
    "ci": "npm run typecheck && npm run build"
  }
}

verbatimModuleSyntax (TS 5.0) reinforces this: it makes import/export emit literal so a regular import is always kept and only import type/export type are erased. That predictability is what a transpiler needs — no guessing whether an import was “used as a value”. It supersedes the old importsNotUsedAsValues and addresses the same single-file concerns isolatedModules flags. (Note: tsc itself still does declaration emit — .d.ts generation — which a transpiler never does, so library builds keep tsc for types even when esbuild produces the JS.)