Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

ts-loader

TypeStrong36.5mMIT9.5.2TypeScript support: included

TypeScript loader for webpack

ts-loader, typescript-loader, webpack, loader, typescript, ts

readme

TypeScript loader for webpack

npm version build and test Downloads node version code style: prettier


ts-loader

This is the TypeScript loader for webpack.

Installation · Report Bug · Request Feature

Table of Contents

Getting Started

Installation

yarn add ts-loader --dev

or

npm install ts-loader --save-dev

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

yarn add typescript --dev

or

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

  1. 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" }
    ]
  }
};

  2. 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 a path string to locate a js module file which exports the function described above, this useful especially in happyPackMode. (Because forked processes cannot serialize functions see more at related issue)

logInfoToStdOut

Type Default Value
boolean false

This is important if you read from stdout or stderr and for proper error handling. The default value ensures that you can read from stdout e.g. via pipes or you use webpack -j to generate json output.

logLevel

Type Default Value
string warn

Can be info, warn or error which limits the log output to the specified log level. Beware of the fact that errors are written to stderr and everything else is written to stderr (or stdout if logInfoToStdOut is true).

silent

Type Default Value
boolean false

If true, no console.log messages will be emitted. Note that most error messages are emitted via webpack which is not affected by this flag.

ignoreDiagnostics

Type Default Value
number[] []

You can squelch certain TypeScript errors by specifying an array of diagnostic codes to ignore.

reportFiles

Type Default Value
string[] []

Only report errors on files matching these glob patterns.

  // in webpack.config.js
  {
    test: /\.ts$/,
    loader: 'ts-loader',
    options: { reportFiles: ['src/**/*.{ts,tsx}', '!src/skip.ts'] }
  }

This can be useful when certain types definitions have errors that are not fatal to your application.

compiler

Type Default Value
string 'typescript'

Allows use of TypeScript compilers other than the official one. Should be set to the NPM name of the compiler, eg ntypescript.

configFile

Type Default Value
string 'tsconfig.json'

Allows you to specify where to find the TypeScript configuration file.

You may provide

  • just a file name. The loader then will search for the config file of each entry point in the respective entry point's containing folder. If a config file cannot be found there, it will travel up the parent directory chain and look for the config file in those folders.
  • a relative path to the configuration file. It will be resolved relative to the respective .ts entry file.
  • an absolute path to the configuration file.

Please note, that if the configuration file is outside of your project directory, you might need to set the context option to avoid TypeScript issues (like TS18003). In this case the configFile should point to the tsconfig.json and context to the project root.

colors

Type Default Value
boolean true

If false, disables built-in colors in logger messages.

errorFormatter

Type Default Value
(message: ErrorInfo, colors: boolean) => string undefined

By default ts-loader formats TypeScript compiler output for an error or a warning in the style:

[tsl] ERROR in myFile.ts(3,14)
      TS4711: you did something very wrong

If that format is not to your taste you can supply your own formatter using the errorFormatter option. Below is a template for a custom error formatter. Please note that the colors parameter is an instance of chalk which you can use to color your output. (This instance will respect the colors option.)

function customErrorFormatter(error, colors) {
  const messageColor =
    error.severity === "warning" ? colors.bold.yellow : colors.bold.red;
  return (
    "Does not compute.... " +
    messageColor(Object.keys(error).map(key => `${key}: ${error[key]}`))
  );
}

If the above formatter received an error like this:

{
  "code":2307,
  "severity": "error",
  "content": "Cannot find module 'components/myComponent2'.",
  "file":"/.test/errorFormatter/app.ts",
  "line":2,
  "character":31
}

It would produce an error message that said:

Does not compute.... code: 2307,severity: error,content: Cannot find module 'components/myComponent2'.,file: /.test/errorFormatter/app.ts,line: 2,character: 31

And the bit after "Does not compute.... " would be red.

compilerOptions

Type Default Value
object {}

Allows overriding TypeScript options. Should be specified in the same format as you would do for the compilerOptions property in tsconfig.json.

instance

Type Default Value
string TODO

Advanced option to force files to go through different instances of the TypeScript compiler. Can be used to force segregation between different parts of your code.

appendTsSuffixTo

Type Default Value
(RegExp | string)[] []

appendTsxSuffixTo

Type Default Value
(RegExp | string)[] []

A list of regular expressions to be matched against filename. If filename matches one of the regular expressions, a .ts or .tsx suffix will be appended to that filename. If you're using HappyPack or thread-loader with ts-loader, you need use the string type for the regular expressions, not RegExp object.

// change this:
{ appendTsSuffixTo: [/\.vue$/] }
// to:
{ appendTsSuffixTo: ['\\.vue$'] }

This is useful for *.vue file format for now. (Probably will benefit from the new single file format in the future.)

Example:

webpack.config.js:

module.exports = {
  entry: "./index.vue",
  output: { filename: "bundle.js" },
  resolve: {
    extensions: [".ts", ".vue"]
  },
  module: {
    rules: [
      { test: /\.vue$/, loader: "vue-loader" },
      {
        test: /\.ts$/,
        loader: "ts-loader",
        options: { appendTsSuffixTo: [/\.vue$/] }
      }
    ]
  }
};

index.vue

<template><p>hello {{msg}}</p></template>
<script lang="ts">
export default {
  data(): Object {
    return {
      msg: "world"
    };
  }
};
</script>

We can handle .tsx by quite similar way:

webpack.config.js:

module.exports = {
    entry: './index.vue',
    output: { filename: 'bundle.js' },
    resolve: {
        extensions: ['.ts', '.tsx', '.vue', '.vuex']
    },
    module: {
        rules: [
            { test: /\.vue$/, loader: 'vue-loader',
              options: {
                loaders: {
                  ts: 'ts-loader',
                  tsx: 'babel-loader!ts-loader',
                }
              }
            },
            { test: /\.ts$/, loader: 'ts-loader', options: { appendTsSuffixTo: [/TS\.vue$/] } }
            { test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/TSX\.vue$/] } }
        ]
    }
}

tsconfig.json (set jsx option to preserve to let babel handle jsx)

{
  "compilerOptions": {
    "jsx": "preserve"
  }
}

index.vue

<script lang="tsx">
export default {
  functional: true,
  render(h, c) {
    return (<div>Content</div>);
  }
}
</script>

Or if you want to use only tsx, just use the appendTsxSuffixTo option only:

            { test: /\.ts$/, loader: 'ts-loader' }
            { test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/\.vue$/] } }

onlyCompileBundledFiles

Type Default Value
boolean false

The default behavior of ts-loader is to act as a drop-in replacement for the tsc command, so it respects the include, files, and exclude options in your tsconfig.json, loading any files specified by those options. The onlyCompileBundledFiles option modifies this behavior, loading only those files that are actually bundled by webpack, as well as any .d.ts files included by the tsconfig.json settings. .d.ts files are still included because they may be needed for compilation without being explicitly imported, and therefore not picked up by webpack.

useCaseSensitiveFileNames

Type Default Value
boolean determined by typescript based on platform

The default behavior of ts-loader is to act as a drop-in replacement for the tsc command, so it respects the useCaseSensitiveFileNames set internally by typescript. The useCaseSensitiveFileNames option modifies this behavior, by changing the way in which ts-loader resolves file paths to compile. Setting this to true can have some performance benefits due to simplifying the file resolution codepath.

allowTsInNodeModules

Type Default Value
boolean false

By default, ts-loader will not compile .ts files in node_modules. You should not need to recompile .ts files there, but if you really want to, use this option. Note that this option acts as a whitelist - any modules you desire to import must be included in the "files" or "include" block of your project's tsconfig.json.

See: https://github.com/Microsoft/TypeScript/issues/12358

  // in webpack.config.js
  {
    test: /\.ts$/,
    loader: 'ts-loader',
    options: { allowTsInNodeModules: true }
  }

And in your tsconfig.json:

  {
    "include": [
      "node_modules/whitelisted_module.ts"
    ],
    "files": [
      "node_modules/my_module/whitelisted_file.ts"
    ]
  }

context

Type Default Value
string undefined

If set, will parse the TypeScript configuration file with given absolute path as base path. Per default the directory of the configuration file is used as base path. Relative paths in the configuration file are resolved with respect to the base path when parsed. Option context allows to set option configFile to a path other than the project root (e.g. a NPM package), while the base path for ts-loader can remain the project root.

Keep in mind that not having a tsconfig.json in your project root can cause different behaviour between ts-loader and tsc. When using editors like VS Code it is advised to add a tsconfig.json file to the root of the project and extend the config file referenced in option configFile. For more information please read the PR that is the base and read the PR that contributed this option.

webpack:

{
  loader: require.resolve('ts-loader'),
  options: {
    context: __dirname,
    configFile: require.resolve('ts-config-react-app')
  }
}

Extending tsconfig.json:

{ "extends": "./node_modules/ts-config-react-app/index" }

Note that changes in the extending file while not be respected by ts-loader. Its purpose is to satisfy the code editor.

experimentalFileCaching

Type Default Value
boolean true

By default whenever the TypeScript compiler needs to check that a file/directory exists or resolve symlinks it makes syscalls. It does not cache the result of these operations and this may result in many syscalls with the same arguments (see comment with example). In some cases it may produce performance degradation.

This flag enables caching for some FS-functions like fileExists, realpath and directoryExists for TypeScript compiler. Note that caches are cleared between compilations.

projectReferences

Type Default Value
boolean false

ts-loader has opt-in support for project references. With this configuration option enabled, ts-loader will incrementally rebuild upstream projects the same way tsc --build does. Otherwise, source files in referenced projects will be treated as if they’re part of the root project.

In order to make use of this option your project needs to be correctly configured to build the project references and then to use them as part of the build. See the Project References Guide and the example code in the examples which can be found here.

Usage with webpack watch

Because TS will generate .js and .d.ts files, you should ignore these files, otherwise watchers may go into an infinite watch loop. For example, when using webpack, you may wish to add this to your webpack.conf.js file:

// for webpack 4
 plugins: [
   new webpack.WatchIgnorePlugin([
     /\.js$/,
     /\.d\.[cm]?ts$/
   ])
 ],

// for webpack 5
plugins: [
  new webpack.WatchIgnorePlugin({
    paths:[
      /\.js$/,
      /\.d\.[cm]ts$/
  ]})
],

It's worth noting that use of the LoaderOptionsPlugin is only supposed to be a stopgap measure. You may want to look at removing it entirely.

Hot Module replacement

We do not support HMR as we did not yet work out a reliable way how to set it up.

If you want to give webpack-dev-server HMR a try, follow the official webpack HMR guide, then tweak a few config options for ts-loader:

  1. Set transpileOnly to true (see transpileOnly for config details and recommendations above).
  2. Inside your HMR acceptance callback function, maybe re-require the module that was replaced.

Contributing

This is your TypeScript loader! We want you to help make it even better. Please feel free to contribute; see the contributor's guide to get started.

History

ts-loader was started by James Brantly, since 2016 John Reilly has been taking good care of it. If you're interested, you can read more about how that came to pass.

License

MIT License

changelog

Changelog

9.5.2

9.5.1

9.5.0

9.4.4

9.4.3

9.4.2

9.4.1

v9.4.0

v9.3.1

v9.3.0

v9.2.9

v9.2.8

v9.2.7

v9.2.6

v9.2.5

v9.2.4

v9.2.3

v9.2.2

v9.2.1

v9.2.0

v9.1.2

v9.1.1

v9.1.0

v9.0.2

v9.0.1

v9.0.0

Breaking changes:

  • minimum webpack version: 5
  • minimum node version: 12

Changes:

v8.4.0

v8.3.0

v8.2.0

v8.1.0

v8.0.18

v8.0.17

v8.0.16

v8.0.15

v8.0.14

v8.0.13

v8.0.12

v8.0.11

v8.0.10

v8.0.9

v8.0.8

v8.0.7

v8.0.6

v8.0.5

v8.0.4

v8.0.3

v8.0.2

v8.0.1

v8.0.0

v7.0.5

v7.0.4

v7.0.3

v7.0.2

v7.0.1

v7.0.0

v6.2.2

v6.2.1

v6.2.0

v6.1.2

v6.1.1

v6.1.0

v6.0.4

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v5.4.5

v5.4.4

v5.4.3

v5.3.3

v5.3.2

v5.3.1

v5.3.0

v5.2.2

v5.2.1

v5.2.0

v5.1.1

v5.1.0

v5.0.0

v4.5.0

v4.4.2

v4.4.1

v4.4.0

v4.3.1

Please note, this bug fix requires that vue-loader users still using v14 should either upgrade to v15 or explicitly pass the same ts-loader options via v14's loaders option. See more details here

v4.3.0

v4.2.0

v4.1.0

v4.0.1

v4.0.0

  • Support webpack 4
  • Drop support for webpack 2/3 BREAKING CHANGE - use ts-loader 3.x if you need webpack 2/3 support
  • Minimum TypeScript version is now 2.4.1 BREAKING CHANGE
  • Deprecated option entryFileCannotBeJs removed' BREAKING CHANGE
  • Start using prettier for the codebase

v3.5.0

v3.4.0

v3.3.1

v3.3.0

v3.2.0

v3.1.1

v3.1.0

v3.0.5

v3.0.4

v3.0.3

  • Fix allowJs @types resolution error (#657, #655) - thanks @johnnyreilly and @roddypratt + @ldrick for providing minimal repro repos which allowed me to fix this long standing bug!

This fix resolves the issue for TypeScript 2.4+ (which is likely 95% of users). For those people stuck on 2.3 or below and impacted by this issue, you should be able to workaround this by setting entryFileCannotBeJs: true in your ts-loader options. This option should be considered deprecated as of this release. The option will likely disappear with the next major version of ts-loader which will drop support for TypeScript 2.3 and below, thus removing the need for this option.

v3.0.0

All changes were made with this PR - thanks @johnnyreilly

(Published to npm as v3.0.2 due to npm publishing issues) thanks @mattlewis92 for noticing!

  • drop support for typescript < 2.0 (no-one seems to be using it and we can simplify the code) BREAKING CHANGE
  • remove entryFileIsJs option; it can be inferred from whether the allowJs TypeScript compiler option has been set.
  • move to webpack 3.0 for test harness
  • drop configFileName support (replaced by configFile) BREAKING CHANGE
  • add support for a custom formatter for output - drop visual studio format (this can be added back if there's clamour for it and people can supply their own formatters in the interim) BREAKING CHANGE
  • make loglevel warn by default (stop outputting typescript version number by default). Fixes #488
  • fix tsc has "module" default to "es2015"when targetting es2015+, but ts-loader does not - thanks @Venryx for the suggestion!
  • switch to build ts-loader / run tests with yarn because of this
  • allow controlling whether the output can contain colours

v2.3.7

v2.3.6

v2.3.5

v2.3.4

v2.3.3

v2.3.2

v2.3.1

v2.3.0

v2.2.2

v2.2.1

v2.2.0

v2.1.0

v2.0.3

v2.0.2

v2.0.1

v2.0.0

Breaking changes:

  • ts-loader now officially only supports webpack 2. ts-loader 2.x may work with webpack 1 but it is not supported. Related to that, all continuous integration tests now run against webpack 2.
  • as webpack 2 does not support node 0.12 neither does ts-loader from now. node 4 at least is required.

v1.3.3

v1.3.2

v1.3.1

v1.3.0

NB Previously the entryFileIsJs option was on by default when allowJs was true. Now it has to be specified directly. Strictly speaking this is a breaking change; however given this is a rarely used option which exists for what is arguably an edge case this is being added without moving to 2.0. If this breaks people then we'll never do this again; I'd be surprised if anyone is relying on this though so we're taking a chance. Related tests have been suffixed "-entryFileIsJs" in the test name.

v1.2.2

v1.2.1

v1.2.0

v1.1.0

v1.0.0

v0.9.5

v0.9.4

v0.9.3

v0.9.2

v0.9.1

v0.9.0

Now built using TypeScript v2.0

v0.8.2

  • Elided imports are now watched (#156, #169)
  • Declaration files for .d.ts files are now emitted (thanks @rob-bateman) (#174, #175)

v0.8.1

  • Add better error messaging when a file in tsconfig.json can not be loaded (#117, #145)
  • Fix incompatibility with html-webpack-plugin (#152, #154)

v0.8.0

  • Add support for emitting declaration files when declaration: true is set (#48, #128)
  • Fix bug with specifying target: es6 and module: commonjs at the same time when using TS 1.7+ (#111, #132, #140).
  • Fix bug with resolving dependencies which are linked using npm link (#134, #141)

v0.7.2

  • Fix regression with watching definition files (#109, #110)

v0.7.1

  • Fix regression with Windows that was introduced in v0.7.0 (#92)

v0.7.0

  • Fix bug with webpack resolution that could sometimes cause TypeScript to not find modules (#92, #102)
  • Loader output is now written to stderr instead of stdout. (#95, #103)

v0.6.1

  • Improve initial build performance significantly for larger projects (#100)
  • Fix issue with nightly (#96)

v0.6.0

  • Remove support for 1.5 and 1.6-beta. TypeScript 1.6 (stable) is the now the lowest version supported.
  • Fix issue when using source maps and Babel in certain situations (#81)
  • Fix issue with nightly (#83)

v0.5.6

  • Add ignoreDiagnostics feature
  • Fix issue with node resolution and noEmitOnError (#71)

v0.5.5

  • Fix issue with nightly (Microsoft/TypeScript#4738)
  • Add support for the NoErrorsPlugin

v0.5.4

  • Fix issue with nightly (Microsoft/TypeScript#4497)

v0.5.3

  • Utilize TypeScript's new custom module resolution logic to integrate with webpack. This essentially means that TypeScript will resolve files exactly the same as webpack does (supporting aliases, etc). See the aliasResolution test for an example. Only supported in TS 1.6 and above.
  • Rework error reporting to resolve certain edge cases with dependencies. In general errors should be much more consistent now in watch mode.
  • Fix issue with targeting ES6 and transpile mode (#36)

v0.5.2

  • Fix issue with TypeScript nightly and new node module resolution strategy (#34)

v0.5.1

  • Tweaked error message output to include error code (#32)
  • Add helpful messages around the TypeScript dependency
    • Suggest how to install TypeScript if it hasn't been installed
    • Show TypeScript version when compiling
    • Warn if TypeScript version is incompatible

v0.5.0

  • Add support for transpileOnly loader option. See README for more information.
  • TypeScript is no longer a dependency of the loader and must be installed separately
  • Loader options can now be set as a property in webpack.config.js
  • TypeScript options can be set through the loader option compilerOptions
  • Improved error reporting
    • Errors from all files in the TypeScript application are now reported in watch mode instead of from just those files that changed. This means that making a breaking change in a dependency will now be correctly reported as an error in the dependent file.
    • Errors with TypeScript options are now reported as webpack errors instead of logged to console
    • Error output no longer contains the filename once from webpack and again in the error message. Instead, the filename is only reported by webpack
    • Fixed issue with latest version of webpack where filenames could be reported twice for the same error in certain situations
  • Using the declaration TypeScript option no longer results in errors
  • Add support for the newLine TypeScript option
  • Tests have been revamped to be full integration tests with nightly builds against the current stable and nightly TypeScript. Many new tests have been added.

v0.4.7

  • Update TypeScript dependency to 1.5 release (1.5.3)

v0.4.6

  • Improve error reporting related to tsconfig.json
    • Fix bug that reported the wrong errors
    • Errors are now reported as webpack errors instead of logged to console
  • Add support for latest TypeScript nightly (#24)

v0.4.5

  • Add silent flag (#22)

v0.4.4

  • Add support for "noLib" compiler option (#19)
  • Make errors easier to parse programmatically (#20)
    • Errors in declaration files are now added to the stats object instead of written to console
    • Errors now include file, rawMessage, and location properties
  • Make --watch option more robust
    • Fix issue where changes to entry file were not detected
    • Fix issue where changes to typing information only did not result in a rebuild (#21)

v0.4.3

  • Fix error locations to be 1-based instead of 0-based (#18)

v0.4.2

  • Rework the way dependencies are loaded (#14)
  • Fix NPM dependency on TypeScript (#15, #16)

v0.4.1

  • Fix Windows issue with paths (#14)

v0.4.0

  • TypeScript 1.5 support! (#14)
  • tsconfig.json support (#2, #9)
  • ES6 target support
  • Remove TS-related options in favor of specifying them in tsconfig.json
  • Add configFileName option for custom tsconfig files

v0.3.4

  • Exclude TS 1.5 as a dependency since there are breaking changes

v0.3.3

  • Add support for reporting errors in declaration files (#10)
  • Add support for watch mode for declaration files (#11)
  • Fix issue with extra sourceMappingURL in output files (#12)

v0.3.2

  • Add support for manually adding files (#6)
  • Add paths to source maps (#8)

v0.3.1

  • Add support for specifying a custom TypeScript compiler

v0.3.0

  • Change how modules are resolved. Imports and declaration file references are now resolved through TypeScript instead of being resolved through webpack's resolve API. This fixes a number of issues and better aligns the loader to work as a replacement for the tsc command. (#3, #4, #5)

v0.2.3

  • Add noImplicitAny option (#2)

v0.2.2

  • Fix issue with source maps

v0.2.1

  • Add colors to error output

v0.2.0

  • Add new configuration options (#1)
    • target, module, sourceMap, instance
    • sourceMap default changed from true to false
  • Workaround issue with TypeScript always emitting Windows-style new lines
  • Add tests

v0.1.0

  • Initial version