This is the typescript loader for webpack.
Tutorials and examples can be found here. Also take a look at our examples.
ts-loader supports the latest and greatest version of TypeScript right back to v1.6. (Including the nightly build.)
A full test suite runs each night (and on each pull request). It runs both on Linux (Travis) and Windows (AppVeyor), testing ts-loader against the following versions of TypeScript:
- TypeScript 2.1
- TypeScript 2.0
- TypeScript 1.8
- TypeScript 1.7
- TypeScript 1.6
and also:
- 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!
ts-loader was designed for Webpack 1.x. All our CI tests run against that.
Webpack 2.0 is on the way and we're excited. If you'd like to see an example setup that works with webpack 2 rc 1 take a look at our example.
There's a known "gotcha" if you are using webpack 2 with the LoaderOptionsPlugin. If you are faced with the Cannot read property 'unsafeCache' of undefined error then you probably need to supply a resolve object as below: (Thanks @jeffijoe!)
new LoaderOptionsPlugin({
debug: false,
options: {
resolve: {
extensions: ['.ts', '.tsx', '.js']
}
}
}) ts-loader works very well in combination with babel and babel-loader. To see an example of this in practice take a look at the example in the official TypeScript Samples or in our examples.
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.
npm install ts-loader
You will also need to install TypeScript if you have not already.
npm install typescript
or if you want to install TypeScript globally
npm install typescript -g
npm link typescript
Use webpack like normal, including webpack --watch and webpack-dev-server, or through another
build system using the Node.js API.
-
Create or update
webpack.config.jslike so:module.exports = { entry: './app.ts', output: { filename: 'bundle.js' }, resolve: { // Add `.ts` and `.tsx` as a resolvable extension. extensions: ['', '.webpack.js', '.web.js', '.ts', '.tsx', '.js'] }, module: { loaders: [ // all files with a `.ts` or `.tsx` extension will be handled by `ts-loader` { test: /\.tsx?$/, loader: 'ts-loader' } ] } }
-
Add a
tsconfig.jsonfile. (The one below is super simple; but you can tweak this to your hearts desire){ "compilerOptions": { } }
The tsconfig.json file controls
TypeScript-related options so that your IDE, the tsc command, and this loader all share the
same options.
When the build fails (i.e. at least one typescript compile error occured), ts-loader does not propagate the build failure to webpack. The upshot of this is you can fail to notice an erroring build. This is inconvenient; particularly in continuous integration scenarios. If you want to ensure that the build failure is propogated it is advised that you make use of the webpack-fail-plugin. This plugin that will make the process return status code 1 when it finishes with errors in single-run mode. Et voilà! Build failure.
For more background have a read of this issue.
Take advantage of the Changelog and Upgrade Guide.
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 set either using a query when specifying the loader or through the ts property in the webpack configuration.
module.exports = {
...
module: {
loaders: [
// specify option using query
{ test: /\.tsx?$/, loader: 'ts-loader?compiler=ntypescript' }
]
},
// specify option using `ts` property - **only do this if you are using webpack 1**
ts: {
compiler: 'ntypescript'
}
}WARNING using the ts property is deprecated as webpack 2 does not allow extension of the webpack.config.js Consequently you are advised to use the query to configure ts-loader. For a full breakdown of the power of query syntax have a read of this.
You may be using webpack 2 and thinking to yourself "gosh I'm going to miss the expressiveness of using JSON to configure ts-loader". Me too. Well, I'm here to tell you there's a get-out-of-jail-free. You might want to use the approach below:
var ts = {
compiler: 'ntypescript'
};
module.exports = {
...
module: {
loaders: [
// specify option using query with the magic of JSON
{ test: /\.tsx?$/, loader: 'ts-loader?' + JSON.stringify(ts) }
]
}
}Boom!!! You're happy now, right?
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. You should also
set the isolatedModules TypeScript option if you plan to ever make use
of this.
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.
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).
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.
You can squelch certain TypeScript errors by specifying an array of diagnostic codes to ignore.
Allows use of TypeScript compilers other than the official one. Should be
set to the NPM name of the compiler, eg ntypescript.
Allows you to specify a custom configuration file.
If true, the TypeScript compiler output for an error or a warning, e.g. (3,14): error TS4711: you did something very wrong, in file myFile will instead be myFile(3,14): error TS4711: you did something very wrong (notice the file name at the beginning). This way Visual Studio will interpret this line and show any errors or warnings in the error list. This enables navigation to the file/line/column through double click.
Allows overriding TypeScript options. Should be specified in the same format
as you would do for the compilerOptions property in tsconfig.json.
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.
To be used in concert with the allowJs compiler option. If your entry file is JS then you'll need to set this option to true. Please note that this is rather unusual and will generally not be necessary when using allowJs.
A list of regular expressions to be matched against filename. If filename matches one of the regular expressions, a .ts suffix will be appended to that filename.
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: {
loaders: [
{ test: /\.vue$/, loader: 'vue' },
{ test: /\.ts$/, loader: 'ts' }
]
},
ts: {
appendTsSuffixTo: [/\.vue$/]
}
}index.vue
<template><p>hello {{msg}}</p></template>
<script lang="ts">
export default {
data(): Object {
return {
msg: "world"
}
},
}
</script>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.
MIT License