TypeScript loader for webpack

<br /> <p align="center"> <h3 align="center">ts-loader</h3> <p align="center"> This is the TypeScript loader for webpack. <br /> <br /> <a href="https://github.com/TypeStrong/ts-loader#installation">Installation</a> · <a href="https://github.com/TypeStrong/ts-loader/issues">Report Bug</a> · <a href="https://github.com/TypeStrong/ts-loader/issues">Request Feature</a> </p> </p>

Getting Started
Contributing
License

Getting Started

Installation

yarn add ts-loader --dev

npm install ts-loader --save-dev

You will also need to install TypeScript if you have not already.

yarn add typescript --dev

npm install typescript --save-dev

Running

Use webpack like normal, including webpack --watch and webpack-dev-server, or through another build system using the Node.js API.

Examples

We have a number of example setups to accommodate different workflows. Our examples can be found here.

We probably have more examples than we need. That said, here's a good way to get started:

I want the simplest setup going. Use "vanilla" ts-loader
I want the fastest compilation that's available. Use fork-ts-checker-webpack-plugin. It performs type checking in a separate process with ts-loader just handling transpilation.

Faster Builds

As your project becomes bigger, compilation time increases linearly. It's because typescript's semantic checker has to inspect all files on every rebuild. The simple solution is to disable it by using the transpileOnly: true option, but doing so leaves you without type checking and will not output declaration files.

You probably don't want to give up type checking; that's rather the point of TypeScript. So what you can do is use the fork-ts-checker-webpack-plugin. It runs the type checker on a separate process, so your build remains fast thanks to transpileOnly: true but you still have the type checking.

If you'd like to see a simple setup take a look at our example.

Yarn Plug’n’Play

ts-loader supports Yarn Plug’n’Play. The recommended way to integrate is using the pnp-webpack-plugin.

Babel

ts-loader works very well in combination with babel and babel-loader. There is an example of this in the official TypeScript Samples.

Compatibility

TypeScript: 3.6.3+
webpack: 5.x+ (please use ts-loader 8.x if you need webpack 4 support)
node: 12.x+

A full test suite runs each night (and on each pull request). It runs both on Linux and Windows, testing ts-loader against major releases of TypeScript. The test suite also runs against TypeScript@next (because we want to use it as much as you do).

If you become aware of issues not caught by the test suite then please let us know. Better yet, write a test and submit it in a PR!

Configuration

Create or update webpack.config.js like so:

module.exports = {
  mode: "development",
  devtool: "inline-source-map",
  entry: "./app.ts",
  output: {
    filename: "bundle.js"
  },
  resolve: {
    // Add `.ts` and `.tsx` as a resolvable extension.
    extensions: [".ts", ".tsx", ".js"],
    // Add support for TypeScripts fully qualified ESM imports.
    extensionAlias: {
     ".js": [".js", ".ts"],
     ".cjs": [".cjs", ".cts"],
     ".mjs": [".mjs", ".mts"]
    }
  },
  module: {
    rules: [
      // all files with a `.ts`, `.cts`, `.mts` or `.tsx` extension will be handled by `ts-loader`
      { test: /\.([cm]?ts|tsx)$/, loader: "ts-loader" }
    ]
  }
};

Add a tsconfig.json file. (The one below is super simple; but you can tweak this to your hearts desire)
```
{
  "compilerOptions": {
    "sourceMap": true
  }
}
```

The tsconfig.json file controls TypeScript-related options so that your IDE, the tsc command, and this loader all share the same options.

`devtool` / sourcemaps

If you want to be able to debug your original source then you can thanks to the magic of sourcemaps. There are 2 steps to getting this set up with ts-loader and webpack.

First, for ts-loader to produce sourcemaps, you will need to set the tsconfig.json option as "sourceMap": true.

Second, you need to set the devtool option in your webpack.config.js to support the type of sourcemaps you want. To make your choice have a read of the devtool webpack docs. You may be somewhat daunted by the choice available. You may also want to vary the sourcemap strategy depending on your build environment. Here are some example strategies for different environments:

devtool: 'inline-source-map' - Solid sourcemap support; the best "all-rounder". Works well with karma-webpack (not all strategies do)
devtool: 'eval-cheap-module-source-map' - Best support for sourcemaps whilst debugging.
devtool: 'source-map' - Approach that plays well with UglifyJsPlugin; typically you might use this in Production

Code Splitting and Loading Other Resources

Loading css and other resources is possible but you will need to make sure that you have defined the require function in a declaration file.

declare var require: {
  <T>(path: string): T;
  (paths: string[], callback: (...modules: any[]) => void): void;
  ensure: (
    paths: string[],
    callback: (require: <T>(path: string) => T) => void
  ) => void;
};

Then you can simply require assets or chunks per the webpack documentation.

require("!style!css!./style.css");

The same basic process is required for code splitting. In this case, you import modules you need but you don't directly use them. Instead you require them at split points. See this example and this example for more details.

TypeScript 2.4 provides support for ECMAScript's new import() calls. These calls import a module and return a promise to that module. This is also supported in webpack - details on usage can be found here. Happy code splitting!

Declaration Files (.d.ts)

To output declaration files (.d.ts), you can set "declaration": true in your tsconfig and set "transpileOnly" to false.

If you use ts-loader with "transpileOnly": true along with fork-ts-checker-webpack-plugin, you will need to configure fork-ts-checker-webpack-plugin to output definition files, you can learn more on the plugin's documentation page: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#typescript-options

To output a built .d.ts file, you can use the DeclarationBundlerPlugin in your webpack config.

Failing the build on TypeScript compilation error

The build should fail on TypeScript compilation errors as of webpack 2. If for some reason it does not, you can use the webpack-fail-plugin.

For more background have a read of this issue.

`baseUrl` / `paths` module resolution

If you want to resolve modules according to baseUrl and paths in your tsconfig.json then you can use the tsconfig-paths-webpack-plugin package. For details about this functionality, see the module resolution documentation.

This feature requires webpack 2.1+ and TypeScript 2.0+. Use the config below or check the package for more information on usage.

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
  ...
  resolve: {
    plugins: [new TsconfigPathsPlugin({ configFile: "./path/to/tsconfig.json" })]
  }
  ...
}

Options

There are two types of options: TypeScript options (aka "compiler options") and loader options. TypeScript options should be set using a tsconfig.json file. Loader options can be specified through the options property in the webpack configuration:

module.exports = {
  ...
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: [
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true
            }
          }
        ]
      }
    ]
  }
}

Loader Options

transpileOnly

Type	Default Value
`boolean`	`false`

If you want to speed up compilation significantly you can set this flag. However, many of the benefits you get from static type checking between different dependencies in your application will be lost. transpileOnly will not speed up compilation of project references.

It's advisable to use transpileOnly alongside the fork-ts-checker-webpack-plugin to get full type checking again. To see what this looks like in practice then either take a look at our example.

Tip: When you add the fork-ts-checker-webpack-plugin to your webpack config, the transpileOnly will default to true, so you can skip that option.

If you enable this option, webpack 4 will give you "export not found" warnings any time you re-export a type:

WARNING in ./src/bar.ts
1:0-34 "export 'IFoo' was not found in './foo'
 @ ./src/bar.ts
 @ ./src/index.ts

The reason this happens is that when typescript doesn't do a full type check, it does not have enough information to determine whether an imported name is a type or not, so when the name is then exported, typescript has no choice but to emit the export. Fortunately, the extraneous export should not be harmful, so you can just suppress these warnings:

module.exports = {
  ...
  stats: {
    warningsFilter: /export .* was not found in/
  }
}

happyPackMode

Type	Default Value
`boolean`	`false`

If you're using HappyPack or thread-loader to parallelise your builds then you'll need to set this to true. This implicitly sets *transpileOnly* to true and WARNING! stops registering all errors to webpack.

It's advisable to use this with the fork-ts-checker-webpack-plugin to get full type checking again. IMPORTANT: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the syntactic diagnostic option like so:

        new ForkTsCheckerWebpackPlugin({
          typescript: {
            diagnosticOptions: {
              semantic: true,
              syntactic: true,
            },
          },
        })

This will ensure that the plugin checks for both syntactic errors (eg const array = [{} {}];) and semantic errors (eg const x: number = '1';). By default the plugin only checks for semantic errors (as when used with ts-loader in transpileOnly mode, ts-loader will still report syntactic errors).

Also, if you are using thread-loader in watch mode, remember to set poolTimeout: Infinity so workers don't die.

resolveModuleName and resolveTypeReferenceDirective

These options should be functions which will be used to resolve the import statements and the <reference types="..."> directives instead of the default TypeScript implementation. It's not intended that these will typically be used by a user of ts-loader - they exist to facilitate functionality such as Yarn Plug’n’Play.

getCustomTransformers

Type
`(program: Program, getProgram: () => Program) => { before?: TransformerFactory<SourceFile>[]; after?: TransformerFactory<SourceFile>[]; afterDeclarations?: TransformerFactory<SourceFile>[]; }`

Provide custom transformers - only compatible with TypeScript 2.3+ (and 2.4 if using transpileOnly mode). For example usage take a look at typescript-plugin-styled-components or our test.

You can also pass