Webpack TypeScript Integration: ts-loader and babel-loader (2026)

Webpack and TypeScript can feel like they’re speaking different languages, but ts-loader and babel-loader bridge that gap, letting you leverage the best of both worlds for modern JavaScript development.

Let’s see this in action. Imagine you have a simple TypeScript file, src/index.ts:

interface User {
  name: string;
  age: number;
}

function greet(user: User): string {
  return `Hello, ${user.name}! You are ${user.age} years old.`;
}

const myUser: User = { name: "Alice", age: 30 };
console.log(greet(myUser));

And a basic webpack.config.js:

const path = require('path');

module.exports = {
  mode: 'development',
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

When you run Webpack with this config, ts-loader takes your index.ts, compiles it into JavaScript (preserving type information internally for its own checks, but outputting plain JS), and Webpack bundles it into dist/bundle.js. If you inspect dist/bundle.js, you’ll see the JavaScript equivalent of your TypeScript, ready for browsers or Node.js.

Now, what if you want to use newer JavaScript features, like arrow functions or async/await, that might not be supported in all target environments? This is where babel-loader comes in, often in conjunction with ts-loader. You can configure Webpack to first let ts-loader handle the TypeScript compilation, and then pass the resulting JavaScript through babel-loader for transpilation down to older JavaScript versions.

Here’s how your webpack.config.js might look with both:

const path = require('path');

module.exports = {
  mode: 'development',
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: ['@babel/preset-env'], // Transpile to modern JS
            },
          },
          {
            loader: 'ts-loader',
            options: {
              // ts-loader specific options can go here
            },
          },
        ],
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

In this setup, Webpack processes the .ts files through the use array from bottom to top (or right to left in this case). ts-loader checks types and converts TypeScript to JavaScript. Then, babel-loader takes that JavaScript and applies the transformations defined in @babel/preset-env, ensuring compatibility with your target environments. The order matters: you want TypeScript checked before Babel potentially simplifies syntax that might be valid TypeScript but less common in older JS.

The core problem both these loaders solve is transforming source code written in one language or dialect (TypeScript, ES6+) into another that your target environment can understand (plain JavaScript, ES5). ts-loader is specifically designed for TypeScript, performing type checking and emitting JavaScript. babel-loader is a general-purpose JavaScript transpiler that uses Babel’s powerful plugin system to transform modern JavaScript syntax into older, more widely compatible versions. By using them together, you get type safety from TypeScript and broad browser compatibility from Babel.

The resolve.extensions array is crucial here. It tells Webpack which file extensions to look for when resolving module requests. By including .ts and .js, Webpack knows to attempt to import files with either extension, and the module.rules then dictate how to process them.

When you run Webpack with this configuration, the output bundle.js in your dist folder will contain JavaScript that is compatible with the environments specified by your Babel presets, while still having originated from your strongly-typed TypeScript source.

One of the most surprising aspects is how ts-loader can be configured to not perform type checking, delegating that responsibility entirely to a separate tsc process. This is often done when you have a robust CI pipeline that runs tsc --noEmit separately. In such cases, you can pass transpileOnly: true in the ts-loader options. This makes ts-loader act purely as a transpiler, significantly speeding up your Webpack build times because it skips the often time-consuming type-checking phase. The trade-off is that you lose immediate feedback on type errors within your Webpack watch process.

The next hurdle you’ll likely encounter is managing different environments (development vs. production) with distinct Webpack configurations, particularly around code minification and source maps.