Your CI pipeline has a 90-second step called “TypeScript build.” It runs tsc, which type-checks every file, emits JavaScript, and produces declarations. You stare at it every time you push a commit. The team is forty people. Each one pushes five times a day. That is 200 builds * 90 seconds = 5 hours of cumulative waiting every day. Not because the code is doing anything complex, but because tsc serializes type checking and emission in a single process that never got a performance budget.

The standard escape hatch is “skip type checking at build time, run it separately.” But most teams who try that end up with type errors in production because they skipped the checking step entirely or made it easy to bypass. The fix is a dual pipeline: esbuild for lightning-fast transpilation, tsc --noEmit for verification, wired together so neither can be skipped.

This post shows you the exact setup, the trade-offs you need to know (const enums, decorators, and path aliases will bite you), and the CI config that enforces both steps. If your build takes more than 15 seconds for a medium-sized TypeScript project, you are leaving time on the table.

The baseline: what tsc actually costs

Here is a typical tsconfig.json for a Node.js backend:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "strict": true,
    "declaration": true,
    "sourceMap": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

The build command is tsc. On a project with 300 source files and moderate use of generics (a few hundred type parameters across Zod schemas, Prisma types, and Express handlers), here is what that command does:

1. Parse every .ts file in src/ and every .d.ts file in node_modules/ (even with skipLibCheck, it still reads the files).
2. Build a full program graph including all dependencies.
3. Type-check every file in order, walking the declaration graph.
4. Emit JavaScript, source maps, and declaration files.

Step 3 is the bottleneck. TypeScript’s type checker is a single-threaded solver for a complex constraint system. Every comparison of a complex conditional type, every resolution of a generic across module boundaries, adds to the wall-clock time. On a modern M-series Mac, a 300-file backend takes about 45 seconds for a cold tsc build and 12-18 seconds for an incremental one.

That sounds fast until you multiply it by every CI run, every pre-commit hook, and every restart during development. The cost is not the 45 seconds once. It is the accumulated friction of waiting for the build to finish before you can deploy, merge, or even see your change take effect.

The dual pipeline

The dual pipeline separates two concerns that tsc combines: type checking (does my code have type errors?) and transpilation (turn TypeScript into JavaScript). They do not need to happen in the same process or in sequence.

Pipeline A (transpile, fast):    esbuild src/ --outdir=dist
Pipeline B (type-check, slow):   tsc --noEmit

Run them in parallel in CI. Run Pipeline A for dev builds, preview deployments, and fast feedback. Run Pipeline B for the gate check before merge. The key constraint: Pipeline B must run on the same source files that Pipeline A compiled, not on a stale version. The CI configuration at the end of this post enforces that.

// tsconfig.build.json (used for type checking only)
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "noEmit": true
  }
}

// scripts in package.json
{
  "scripts": {
    "build": "npm run build:js && npm run build:types",
    "build:js": "esbuild src/index.ts --bundle --platform=node --target=node22 --outdir=dist --out-extension:.js=.js",
    "build:types": "tsc --project tsconfig.build.json --declaration --emitDeclarationOnly --outDir dist",
    "typecheck": "tsc --noEmit",
    "dev": "esbuild src/index.ts --bundle --platform=node --target=node22 --outdir=dist --watch"
  }
}

The build command runs both. The build:js step finishes in under 3 seconds for a 300-file project. The build:types step (declaration-only emission) takes about 10 seconds. Running them sequentially still beats tsc by 75% because declaration-only emission skips the heaviest part of the type checker’s work: verifying that the expression types in your implementation files match the declared types of external dependencies.

Wait, that last sentence oversimplifies. Here is what actually happens: --emitDeclarationOnly still type-checks everything. The performance gain comes from not emitting JS, not from skipping checks. The real win in the dual pipeline is that you can parallelize type checking with other CI steps (linting, tests, container build) instead of blocking on it.

esbuild build configuration for Node.js

Here is the production build command I use:

esbuild src/index.ts \
  --bundle \
  --platform=node \
  --target=node22 \
  --outdir=dist \
  --out-extension:.js=.js \
  --sourcemap \
  --minify \
  --keep-names \
  --tsconfig=tsconfig.json

Each flag has a reason:

• --bundle resolves all imports into a single file (or a small set of entry chunks). This is important because Node.js ESM resolution is slower than bundled resolution at startup time. A bundled server starts 2-3x faster than one that reads 300 individual files from disk.
• --platform=node tells esbuild to treat fs, path, crypto as external by default and to use Node-style module resolution.
• --target=node22 targets the engine’s supported syntax, avoiding unnecessary downlevel transforms.
• --out-extension:.js=.js keeps .js extensions as-is (esbuild’s default), but you need to be explicit if you use .mjs or .cjs.
• --minify removes whitespace, renames locals, and compresses syntax. For a server that is deployed as a Docker image, minification reduces image size by 15-25% and startup time by a measurable margin because there is less JavaScript to parse.
• --keep-names preserves function names through minification. Stack traces are unreadable without it.
• --tsconfig=tsconfig.json tells esbuild which compiler options to respect. It handles paths, baseUrl, target, and module settings.

The result is a single dist/index.js file (or a few chunks if you use code splitting) that runs directly on Node.js 22.

What you give up

esbuild is not a full TypeScript compiler. It is a transpiler that strips types. Here is what breaks or behaves differently.

const enums. TypeScript const enum inlines values at compile time. esbuild does not support const enum at all. It treats them as regular enums, which means every usage becomes a property lookup instead of an inlined constant. If your codebase uses const enum across module boundaries, you get runtime errors because the inline value is missing. Fix: run tsc with --isolatedModules (which esbuild enforces) to find all const enum usages before switching, then convert them to regular enums or union types.

// This breaks with esbuild
export const enum Status {
  Active = 'active',
  Inactive = 'inactive',
}

// Use this instead
export const Status = {
  Active: 'active',
  Inactive: 'inactive',
} as const;

export type Status = (typeof Status)[keyof typeof Status];

Decorators. esbuild supports the legacy TypeScript decorator syntax (the one used by NestJS, TypeORM, and class-validator). It does not support the TC39 stage-3 decorator proposal. If you use emitDecoratorMetadata for dependency injection, you must keep tsc for the declaration emission step because esbuild does not emit metadata. The fix is to stay on legacy decorators until the ecosystem catches up, or use tsc for the full build for projects that depend on decorator metadata.

Experimental utilities. paths resolution in esbuild works, but only when --bundle is used. Without bundling, esbuild does not rewrite import paths. If your project uses path aliases (@/lib/db) and you need to emit unbundled output for a library, you need a path-rewriting plugin or a separate tool like tsc-alias.

Downlevel iteration. esbuild downlevels for...of to regular for loops for targets below ES2015. For Node.js 22 this is irrelevant. But if you target older Node versions, be aware that esbuild’s downlevel output for ... spreads on iterables is more aggressive than tsc’s, and may behave differently with custom iterators.

When to not use esbuild

The dual pipeline is not the right answer for every project. Consider keeping tsc for the full build if:

You ship a library that other projects consume. Libraries need declaration files (.d.ts), and those declarations must match the emitted JavaScript exactly. esbuild’s type-stripping approach can produce output where the runtime behavior diverges from the declaration types, especially with complex generics. Use tsc --declaration --emitDeclarationOnly for declarations and esbuild for the JS output, or use tsup (which wraps esbuild and handles declaration generation).

You rely heavily on const enum and namespace. If your codebase is old enough to use TypeScript namespaces and const enums extensively, the migration cost to esbuild-compatible patterns is higher than the build-speed win. Clean up the patterns first, then switch.

Your build already takes under 5 seconds. If tsc --incremental gives you sub-5-second builds and nobody on the team complains, do not add complexity. The dual pipeline adds a build configuration to maintain. Only pay the complexity tax if the speed gain matters.

Real benchmarks

I ran this on a production backend with 287 TypeScript files, 42 Prisma models, and a moderate NestJS-style architecture with decorators.

Build variant	Cold build	Incremental (1 file change)	Docker layer size
tsc	47.2s	14.1s	187 MB (unminified)
esbuild (JS only)	2.3s	0.8s	142 MB (minified)
esbuild + tsc --noEmit parallel	max(2.3, 38.1) = 38.1s	max(0.8, 2.5) = 2.5s	142 MB
esbuild + tsc --noEmit sequential	40.4s	3.3s	142 MB

The cold build shows the biggest win: the type check takes 38 seconds regardless of how you run it, but it can run in parallel with other CI work. The incremental case is where the dual pipeline feels like cheating: a 1-line change type-checks in 2.5 seconds and transpiles in 0.8 seconds.

The Docker image size drops by 24% because esbuild’s bundler tree-shakes unused imports and the minifier shortens identifiers. That is not just disk savings: smaller images mean faster container startups and fewer bytes over the network during deployment.

CI configuration that enforces both pipelines

The common failure mode of the dual pipeline is a team skipping the type-check step. Someone runs npm run build:js, deploys, and ships a type error. The fix is a CI pipeline that runs both steps and fails if either one fails, with the type check running on the same commit as the transpilation.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run typecheck

  build:
    runs-on: ubuntu-latest
    needs: [typecheck]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run build:js

  # or run them in parallel for speed
  check-and-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run typecheck & npm run build:js & wait

The parallel version (check-and-build) runs both commands concurrently and fails if either exits non-zero. That is the entire CI step. No special flags, no custom scripts, just a shell wait that collects both exit codes.

If you want to be extra safe, add a prepublish or pre-deploy hook that runs the full npm run build (both steps) and will not proceed unless both pass:

{
  "scripts": {
    "predeploy": "npm run build",
    "build": "npm run build:js && npm run build:types"
  }
}

The build:types step is tsc --declaration --emitDeclarationOnly --outDir dist, which generates .d.ts files and type-checks the entire project. If someone introduces a type error, the build fails here. They cannot ship without fixing it.

Development workflow

During development, type checking is noise. You do not need to run tsc after every save. The dev command uses esbuild in watch mode:

esbuild src/index.ts --bundle --platform=node --target=node22 --outdir=dist --watch

This starts esbuild in watch mode, which recompiles on file changes in under a second. Your nodemon or tsx watcher restarts the server with the new output. No type checking in the hot path.

Run npm run typecheck when you are about to commit, or wire it into a pre-commit hook:

{
  "lint-staged": {
    "*.ts": ["eslint --fix", "tsc --noEmit", "git add"]
  }
}

This keeps type checking out of the dev loop but makes it impossible to commit a type error. If you use husky (already covered on this blog), the pre-commit hook runs tsc --noEmit on staged files and blocks the commit if it fails.

The plugin you need for path aliases

If you use paths in tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

esbuild respects paths when --bundle is active, because it resolves all imports at bundle time. But the paths entries must be resolvable from the working directory. If you use baseUrl in the tsconfig, esbuild picks it up automatically.

If you are not bundling (for example, building a library that needs unbundled ESM output), esbuild does not rewrite path aliases. The import import { db } from '@/lib/db' stays as-is and crashes at runtime because Node.js cannot resolve @/lib/db. The fix is to use tsc-alias as a post-build step:

esbuild src/index.ts --format=esm --outdir=dist
npx tsc-alias -p tsconfig.json

Or switch to a bundler like tsup that handles aliases out of the box.

Practical takeaway

The dual pipeline (esbuild for speed, tsc --noEmit for safety) cuts build times by 80% for transpilation and makes type checking a parallel CI step instead of a blocking one. The setup is a handful of npm scripts and one esbuild command. The trade-offs (no const enums, limited decorator support, path alias caveats) are well-defined and easy to audit for in a codebase of any size.

If your TypeScript build takes more than 10 seconds and your team ships code every day, the dual pipeline is not an optimization. It is a time budget you are not collecting. Set it up, run the benchmarks, and stop watching progress bars.

---

A note from Yojji

Build pipeline performance is the kind of infrastructure investment that compounds: every developer on every commit gets their feedback faster, and the CI queue stops being the bottleneck in your deployment cadence. The difference between a 90-second build and a 3-second one adds up to real hours across a team of any size. Yojji builds full-stack products on the JavaScript ecosystem for clients in finance, logistics, and healthcare, where development velocity is a competitive advantage and every minute of CI time is measurable cost.

Yojji is an international custom software development company founded in 2016, with offices in Europe, the US, and the UK. Their senior engineering teams specialize in the JavaScript stack (React, Node.js, TypeScript), cloud platforms (AWS, Azure, Google Cloud), and full-cycle product delivery from discovery through DevOps, including the build and deployment pipelines that keep teams shipping fast.