link管理
链接快照平台
- 输入网页链接，自动生成快照
- 标签化管理网页链接
相关文章推荐
|
重情义的马克杯 · TypeScript and React: ...· 2 天前 · |
|
|
睿智的小蝌蚪 · TypeScript React ...· 2 天前 · |
|
|
八块腹肌的冲锋衣 · ReScript, TypeScript: ...· 2 天前 · |
|
|
刚毅的长颈鹿 · TypeScript ...· 昨天 · |
|
|
独立的电影票 · typescript 数组初始化 - CSDN文库· 昨天 · |
|
|
帅气的登山鞋 · ADO.NET Core ...· 2 月前 · |
|
|
还单身的松鼠 · GitHub - ...· 2 月前 · |
|
|
爽快的莲藕 · 杭州市人民政府办公厅关于加强轨道交通建设运营 ...· 3 月前 · |
|
|
腼腆的八宝粥 · 楚怀王从秦国逃脱后，为何没一个国家敢收留他， ...· 3 月前 · |
|
|
玩足球的闹钟 · SSH登录报错Host key ...· 3 月前 · |
| 1 |
# TypeScript loader for webpack
|
| 3 |
[
](
https://www.npmjs.com/package/ts-loader
)
|
| 4 |
[
](
https://travis-ci.org/TypeStrong/ts-loader
)
|
| 5 |
[
](
https://ci.appveyor.com/project/JohnReilly/ts-loader/branch/master
)
|
| 6 |
[
](
https://npmjs.org/package/ts-loader
)
|
| 7 |
[
](
https://www.npmjs.com/package/ts-loader
)
|
| 8 |
[
](
https://github.com/prettier/prettier
)
|
| 9 |
[
](
https://gitter.im/TypeStrong/ts-loader
)
|
| 11 |
This is the TypeScript loader for webpack.
|
| 13 |
## Getting Started
|
| 15 |
### Examples
|
| 17 |
We have a number of example setups to accommodate different workflows. Our examples can be found [
here
](
examples/
).
|
| 19 |
We probably have more examples than we need. That said, here's a good way to get started:
|
| 21 |
-
I want the simplest setup going. Use "[
vanilla
](
examples/vanilla
)" ts-loader
|
| 22 |
-
I want the fastest compilation that's available. Use [
fork-ts-checker-webpack-plugin
](
https://github.com/Realytics/fork-ts-checker-webpack-plugin
). It performs type checking in a separate process with
`ts-loader`
just handling transpilation.
|
| 24 |
### Faster Builds
|
| 26 |
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*
.
|
| 28 |
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
](
https://github.com/Realytics/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. Also, the plugin has several optimizations to make incremental type checking faster (AST cache, multiple workers).
|
| 30 |
If you'd like to see a simple setup take a look at [
our simple example
](
examples/fork-ts-checker-webpack-plugin/
). For a more complex setup take a look at our [
more involved example
](
examples/react-babel-karma-gulp
).
|
| 32 |
### Yarn Plug’n’Play
|
| 34 |
`ts-loader`
supports [
Yarn Plug’n’Play
](
https://yarnpkg.com/en/docs/pnp
). The recommended way to integrate is using the [
pnp-webpack-plugin
](
https://github.com/arcanis/pnp-webpack-plugin#ts-loader-integration
).
|
| 36 |
### Babel
|
| 38 |
ts-loader works very well in combination with [
babel
](
https://babeljs.io/
) and [
babel-loader
](
https://github.com/babel/babel-loader
). There is an [
example
](
https://github.com/Microsoft/TypeScriptSamples/tree/master/react-flux-babel-karma
) of this in the official [
TypeScript Samples
](
https://github.com/Microsoft/TypeScriptSamples
). Alternatively take a look at our own [
example
](
examples/react-babel-karma-gulp
).
|
| 40 |
### Parallelising Builds
|
| 42 |
It's possible to parallelise your builds. Historically this was useful from a performance perspective with webpack 2 / 3. [
With webpack 4+ there appears to be significantly less benefit and perhaps even cost.
](
https://blog.johnnyreilly.com/2018/12/you-might-not-need-thread-loader.html
)
|
| 44 |
But if that's what you want to do, there's two ways to achieve this: [
happypack
](
https://github.com/amireh/happypack
) and [
thread-loader
](
https://github.com/webpack-contrib/thread-loader
). Both should be used in combination with [
fork-ts-checker-webpack-plugin
](
https://github.com/Realytics/fork-ts-checker-webpack-plugin
) for typechecking.)
|
| 46 |
To read more, look at [
this post
](
https://medium.com/webpack/typescript-webpack-super-pursuit-mode-83cc568dea79
) by [
@johnny_reilly
](
https://twitter.com/johnny_reilly
) on the webpack publication channel.
|
| 48 |
If you'd like find out further ways to improve your build using the watch API then take a look at [
this post
](
https://medium.com/@kenneth_chau/speeding-up-webpack-typescript-incremental-builds-by-7x-3912ba4c1d15
) by [
@kenneth_chau
](
https://twitter.com/kenneth_chau
).
|
| 50 |
### Installation
|
| 52 |
```
|
| 53 |
yarn add ts-loader --dev
|
| 54 |
```
|
| 56 |
or
|
| 58 |
```
|
| 59 |
npm install ts-loader --save-dev
|
| 60 |
```
|
| 62 |
You will also need to install TypeScript if you have not already.
|
| 64 |
```
|
| 65 |
yarn add typescript --dev
|
| 66 |
```
|
| 68 |
or
|
| 70 |
```
|
| 71 |
npm install typescript --save-dev
|
| 72 |
```
|
| 74 |
### Running
|
| 76 |
Use webpack like normal, including
`webpack --watch`
and
`webpack-dev-server`
, or through another
|
| 77 |
build system using the [
Node.js API
](
http://webpack.github.io/docs/node.js-api.html
).
|
| 79 |
### Compatibility
|
| 81 |
*
TypeScript: 2.4.1+
|
| 82 |
*
webpack: 4.x+ (please use ts-loader 3.x if you need webpack 2 or 3 support)
|
| 83 |
*
node: 6.11.5 minimum (aligned with webpack 4)
|
| 85 |
A full test suite runs each night (and on each pull request). It runs both on [
Linux
](
https://travis-ci.org/TypeStrong/ts-loader
) and [
Windows
](
https://ci.appveyor.com/project/JohnReilly/ts-loader
), 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).
|
| 87 |
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!
|
| 89 |
### Configuration
|
| 91 |
1.
Create or update
`webpack.config.js`
like so:
|
| 93 |
```javascript
|
| 94 |
module.exports = {
|
| 95 |
mode: "development",
|
| 96 |
devtool: "inline-source-map",
|
| 97 |
entry: "./app.ts",
|
| 98 |
output: {
|
| 99 |
filename: "bundle.js"
|
| 100 |
},
|
| 101 |
resolve: {
|
| 102 |
// Add `.ts` and `.tsx` as a resolvable extension.
|
| 103 |
extensions: [".ts", ".tsx", ".js"]
|
| 104 |
},
|
| 105 |
module: {
|
| 106 |
rules: [
|
| 107 |
// all files with a `.ts` or `.tsx` extension will be handled by `ts-loader`
|
| 108 |
{ test: /\.tsx?$/, loader: "ts-loader" }
|
| 109 |
]
|
| 110 |
}
|
| 111 |
};
|
| 112 |
```
|
| 114 |
2. Add a [`tsconfig.json`](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) file. (The one below is super simple; but you can tweak this to your hearts desire)
|
| 116 |
```json
|
| 117 |
{
|
| 118 |
"compilerOptions": {
|
| 119 |
"sourceMap": true
|
| 120 |
}
|
| 121 |
}
|
| 122 |
```
|
| 124 |
The [tsconfig.json](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html) file controls
|
| 125 |
TypeScript-related options so that your IDE, the `tsc` command, and this loader all share the
|
| 126 |
same options.
|
| 128 |
#### `devtool` / sourcemaps
|
| 130 |
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.
|
| 132 |
First, for ts-loader to produce **sourcemaps**, you will need to set the [tsconfig.json](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html) option as `"sourceMap": true`.
|
| 134 |
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](https://webpack.js.org/configuration/devtool/). 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:
|
| 136 |
* `devtool: 'inline-source-map'` - Solid sourcemap support; the best "all-rounder". Works well with karma-webpack (not all strategies do)
|
| 137 |
* `devtool: 'cheap-module-eval-source-map'` - Best support for sourcemaps whilst debugging.
|
| 138 |
* `devtool: 'source-map'` - Approach that plays well with UglifyJsPlugin; typically you might use this in Production
|
| 140 |
### Code Splitting and Loading Other Resources
|
| 142 |
Loading css and other resources is possible but you will need to make sure that
|
| 143 |
you have defined the `require` function in a [declaration file](https://www.typescriptlang.org/docs/handbook/writing-declaration-files.html).
|
| 145 |
```typescript
|
| 146 |
declare var require: {
|
| 147 |
<T>(path: string): T;
|
| 148 |
(paths: string[], callback: (...modules: any[]) => void): void;
|
| 149 |
ensure: (
|
| 150 |
paths: string[],
|
| 151 |
callback: (require: <T>(path: string) => T) => void
|
| 152 |
) => void;
|
| 153 |
};
|
| 154 |
```
|
| 156 |
Then you can simply require assets or chunks per the [
webpack documentation
](
https://webpack.js.org/guides/code-splitting/
).
|
| 158 |
```javascript
|
| 159 |
require("!style!css!./style.css");
|
| 160 |
```
|
| 162 |
The same basic process is required for code splitting. In this case, you
`import`
modules you need but you
|
| 163 |
don't directly use them. Instead you require them at [
split points
](
http://webpack.github.io/docs/code-splitting.html#defining-a-split-point
). See [
this example
](
test/comparison-tests/codeSplitting
) and [
this example
](
test/comparison-tests/es6codeSplitting
) for more details.
|
| 165 |
[
TypeScript 2.4 provides support for ECMAScript's new `import()` calls. These calls import a module and return a promise to that module.
](
https://blogs.msdn.microsoft.com/typescript/2017/06/12/announcing-typescript-2-4-rc/
) This is also supported in webpack - details on usage can be found [
here
](
https://webpack.js.org/guides/code-splitting-async/#dynamic-import-import-
). Happy code splitting!
|
| 167 |
### Declarations (.d.ts)
|
| 169 |
To output a built .d.ts file, you can set
`"declaration": true`
in your tsconfig, and use the [
DeclarationBundlerPlugin
](
https://www.npmjs.com/package/declaration-bundler-webpack-plugin
) in your webpack config.
|
| 171 |
### Failing the build on TypeScript compilation error
|
| 173 |
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
](
https://www.npmjs.com/package/webpack-fail-plugin
).
|
| 175 |
For more background have a read of [
this issue
](
https://github.com/TypeStrong/ts-loader/issues/108
).
|
| 177 |
### `baseUrl` / `paths` module resolution
|
| 179 |
If you want to resolve modules according to
`baseUrl`
and
`paths`
in your
`tsconfig.json`
then you can use the [
tsconfig-paths-webpack-plugin
](
https://www.npmjs.com/package/tsconfig-paths-webpack-plugin
) package. For details about this functionality, see the [
module resolution documentation
](
https://www.typescriptlang.org/docs/handbook/module-resolution.html#base-url
).
|
| 181 |
This feature requires webpack 2.1+ and TypeScript 2.0+. Use the config below or check the [
package
](
https://github.com/dividab/tsconfig-paths-webpack-plugin/blob/master/README.md
) for more information on usage.
|
| 183 |
```javascript
|
| 184 |
const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');
|
| 186 |
module.exports = {
|
| 187 |
...
|
| 188 |
resolve: {
|
| 189 |
plugins: [new TsconfigPathsPlugin({ /*configFile: "./path/to/tsconfig.json" */ })]
|
| 190 |
}
|
| 191 |
...
|
| 192 |
}
|
| 193 |
```
|
| 195 |
### Options
|
| 197 |
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:
|
| 199 |
```javascript
|
| 200 |
module.exports = {
|
| 201 |
...
|
| 202 |
module: {
|
| 203 |
rules: [
|
| 204 |
{
|
| 205 |
test: /\.tsx?$/,
|
| 206 |
use: [
|
| 207 |
{
|
| 208 |
loader: 'ts-loader',
|
| 209 |
options: {
|
| 210 |
transpileOnly: true
|
| 211 |
}
|
| 212 |
}
|
| 213 |
]
|
| 214 |
}
|
| 215 |
]
|
| 216 |
}
|
| 217 |
}
|
| 218 |
```
|
| 220 |
### Loader Options
|
| 222 |
#### transpileOnly _(boolean) (default=false)_
|
| 224 |
If you want to speed up compilation significantly you can set this flag.
|
| 225 |
However, many of the benefits you get from static type checking between
|
| 226 |
different dependencies in your application will be lost.
|
| 228 |
It's advisable to use
`transpileOnly`
alongside the [
fork-ts-checker-webpack-plugin
](
https://github.com/Realytics/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 simple example
](
examples/fork-ts-checker-webpack-plugin
). For a more complex setup take a look at our [
more involved example
](
examples/react-babel-karma-gulp
).
|
| 230 |
If you enable this option, webpack 4 will give you "export not found" warnings any time you re-export a type:
|
| 232 |
```
|
| 233 |
WARNING in ./src/bar.ts
|
| 234 |
1:0-34 "export 'IFoo' was not found in './foo'
|
| 235 |
@ ./src/bar.ts
|
| 236 |
@ ./src/index.ts
|
| 237 |
```
|
| 239 |
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:
|
| 241 |
```javascript
|
| 242 |
module.exports = {
|
| 243 |
...
|
| 244 |
stats: {
|
| 245 |
warningsFilter: /export .* was not found in/
|
| 246 |
}
|
| 247 |
}
|
| 248 |
```
|
| 250 |
#### happyPackMode _(boolean) (default=false)_
|
| 252 |
If you're using [
HappyPack
](
https://github.com/amireh/happypack
) or [
thread-loader
](
https://github.com/webpack-contrib/thread-loader
) to parallise 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.
|
| 254 |
It's advisable to use this with the [
fork-ts-checker-webpack-plugin
](
https://github.com/Realytics/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 simple HappyPack example
](
examples/happypack
) / [
our simple thread-loader example
](
examples/thread-loader
). For a more complex setup take a look at our [
more involved HappyPack example
](
examples/react-babel-karma-gulp-happypack
) / [
more involved thread-loader example
](
examples/react-babel-karma-gulp-thread-loader
).
**_IMPORTANT_*
*: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the
`checkSyntacticErrors`
option like so:
|
| 256 |
```javascript
|
| 257 |
new ForkTsCheckerWebpackPlugin({ checkSyntacticErrors: true })
|
| 258 |
```
|
| 260 |
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).
|
| 262 |
Also, if you are using
`thread-loader`
in watch mode, remember to set
`poolTimeout: Infinity`
so workers don't die.
|
| 264 |
#### resolveModuleName and resolveTypeReferenceDirective:
|
| 266 |
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
](
https://yarnpkg.com/en/docs/pnp
).
|
| 268 |
#### getCustomTransformers _( (program: Program) => { before?: TransformerFactory<SourceFile>[]; after?: TransformerFactory<SourceFile>[]; } )_
|
| 270 |
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
](
https://github.com/Igorbek/typescript-plugin-styled-components
) or our [
test
](
test/comparison-tests/customTransformer
).
|
| 272 |
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
](
https://github.com/Igorbek/typescript-plugin-styled-components/issues/6#issue-303387183
))
|
| 274 |
#### logInfoToStdOut _(boolean) (default=false)_
|
| 276 |
This is important if you read from stdout or stderr and for proper error handling.
|
| 277 |
The default value ensures that you can read from stdout e.g. via pipes or you use webpack -j to generate json output.
|
| 279 |
#### logLevel _(string) (default=warn)_
|
| 281 |
Can be
`info`
,
`warn`
or
`error`
which limits the log output to the specified log level.
|
| 282 |
Beware of the fact that errors are written to stderr and everything else is written to stderr (or stdout if logInfoToStdOut is true).
|
| 284 |
#### silent _(boolean) (default=false)_
|
| 286 |
If
`true`
, no console.log messages will be emitted. Note that most error
|
| 287 |
messages are emitted via webpack which is not affected by this flag.
|
| 289 |
#### ignoreDiagnostics _(number[]) (default=[])_
|
| 291 |
You can squelch certain TypeScript errors by specifying an array of diagnostic
|
| 292 |
codes to ignore.
|
| 294 |
#### reportFiles _(string[]) (default=[])_
|
| 296 |
Only report errors on files matching these glob patterns.
|
| 298 |
```javascript
|
| 299 |
// in webpack.config.js
|
| 300 |
{
|
| 301 |
test: /\.ts$/,
|
| 302 |
loader: 'ts-loader',
|
| 303 |
options: { reportFiles: ['src/**/*.{ts,tsx}', '!src/skip.ts'] }
|
| 304 |
}
|
| 305 |
```
|
| 307 |
This can be useful when certain types definitions have errors that are not fatal to your application.
|
| 309 |
#### compiler _(string) (default='typescript')_
|
| 311 |
Allows use of TypeScript compilers other than the official one. Should be
|
| 312 |
set to the NPM name of the compiler, eg [
`ntypescript`
](
https://github.com/basarat/ntypescript
).
|
| 314 |
#### configFile _(string) (default='tsconfig.json')_
|
| 316 |
Allows you to specify where to find the TypeScript configuration file.
|
| 318 |
You may provide
|
| 320 |
*
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.
|
| 321 |
*
a relative path to the configuration file. It will be resolved relative to the respective
`.ts`
entry file.
|
| 322 |
*
an absolute path to the configuration file.
|
| 324 |
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).
|
| 325 |
In this case the
`configFile`
should point to the
`tsconfig.json`
and
`context`
to the project root.
|
| 327 |
#### colors _(boolean) (default=true)_
|
| 329 |
If
`false`
, disables built-in colors in logger messages.
|
| 331 |
#### errorFormatter _((message: ErrorInfo, colors: boolean) => string) (default=undefined)_
|
| 333 |
By default ts-loader formats TypeScript compiler output for an error or a warning in the style:
|
| 335 |
```
|
| 336 |
[tsl] ERROR in myFile.ts(3,14)
|
| 337 |
TS4711: you did something very wrong
|
| 338 |
```
|
| 340 |
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`
](
https://github.com/chalk/chalk
) which you can use to color your output. (This instance will respect the
`colors`
option.)
|
| 342 |
```javascript
|
| 343 |
function customErrorFormatter(error, colors) {
|
| 344 |
const messageColor =
|
| 345 |
error.severity === "warning" ? colors.bold.yellow : colors.bold.red;
|
| 346 |
return (
|
| 347 |
"Does not compute.... " +
|
| 348 |
messageColor(Object.keys(error).map(key => `${key}: ${error[key]}`))
|
| 349 |
);
|
| 350 |
}
|
| 351 |
```
|
| 353 |
If the above formatter received an error like this:
|
| 355 |
```json
|
| 356 |
{
|
| 357 |
"code":2307,
|
| 358 |
"severity": "error",
|
| 359 |
"content": "Cannot find module 'components/myComponent2'.",
|
| 360 |
"file":"/.test/errorFormatter/app.ts",
|
| 361 |
"line":2,
|
| 362 |
"character":31
|
| 363 |
}
|
| 364 |
```
|
| 366 |
It would produce an error message that said:
|
| 368 |
```
|
| 369 |
Does not compute.... code: 2307,severity: error,content: Cannot find module 'components/myComponent2'.,file: /.test/errorFormatter/app.ts,line: 2,character: 31
|
| 370 |
```
|
| 372 |
And the bit after "Does not compute.... " would be red.
|
| 374 |
#### compilerOptions _(object) (default={})_
|
| 376 |
Allows overriding TypeScript options. Should be specified in the same format
|
| 377 |
as you would do for the
`compilerOptions`
property in tsconfig.json.
|
| 379 |
#### instance _(string)_
|
| 381 |
Advanced option to force files to go through different instances of the
|
| 382 |
TypeScript compiler. Can be used to force segregation between different parts
|
| 383 |
of your code.
|
| 385 |
#### appendTsSuffixTo _(RegExp[]) (default=[])_
|
| 387 |
#### appendTsxSuffixTo _(RegExp[]) (default=[])_
|
| 389 |
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.
|
| 391 |
This is useful for
`*.vue`
[
file format
](
https://vuejs.org/v2/guide/single-file-components.html
) for now. (Probably will benefit from the new single file format in the future.)
|
| 393 |
Example:
|
| 395 |
webpack.config.js:
|
| 397 |
```javascript
|
| 398 |
module.exports = {
|
| 399 |
entry: "./index.vue",
|
| 400 |
output: { filename: "bundle.js" },
|
| 401 |
resolve: {
|
| 402 |
extensions: [".ts", ".vue"]
|
| 403 |
},
|
| 404 |
module: {
|
| 405 |
rules: [
|
| 406 |
{ test: /\.vue$/, loader: "vue-loader" },
|
| 407 |
{
|
| 408 |
test: /\.ts$/,
|
| 409 |
loader: "ts-loader",
|
| 410 |
options: { appendTsSuffixTo: [/\.vue$/] }
|
| 411 |
}
|
| 412 |
]
|
| 413 |
}
|
| 414 |
};
|
| 415 |
```
|
| 417 |
index.vue
|
| 419 |
```vue
|
| 420 |
<template><p>hello {{msg}}</p></template>
|
| 421 |
<script lang="ts">
|
| 422 |
export default {
|
| 423 |
data(): Object {
|
| 424 |
return {
|
| 425 |
msg: "world"
|
| 426 |
};
|
| 427 |
}
|
| 428 |
};
|
| 429 |
</script>
|
| 430 |
```
|
| 432 |
We can handle
`.tsx`
by quite similar way:
|
| 434 |
webpack.config.js:
|
| 436 |
```javascript
|
| 437 |
module.exports = {
|
| 438 |
entry: './index.vue',
|
| 439 |
output: { filename: 'bundle.js' },
|
| 440 |
resolve: {
|
| 441 |
extensions: ['.ts', '.tsx', '.vue', '.vuex']
|
| 442 |
},
|
| 443 |
module: {
|
| 444 |
rules: [
|
| 445 |
{ test: /\.vue$/, loader: 'vue-loader',
|
| 446 |
options: {
|
| 447 |
loaders: {
|
| 448 |
ts: 'ts-loader',
|
| 449 |
tsx: 'babel-loader!ts-loader',
|
| 450 |
}
|
| 451 |
}
|
| 452 |
},
|
| 453 |
{ test: /\.ts$/, loader: 'ts-loader', options: { appendTsSuffixTo: [/TS\.vue$/] } }
|
| 454 |
{ test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/TSX\.vue$/] } }
|
| 455 |
]
|
| 456 |
}
|
| 457 |
}
|
| 458 |
```
|
| 460 |
tsconfig.json (set
`jsx`
option to
`preserve`
to let babel handle jsx)
|
| 462 |
```json
|
| 463 |
{
|
| 464 |
"compilerOptions": {
|
| 465 |
"jsx": "preserve"
|
| 466 |
}
|
| 467 |
}
|
| 468 |
```
|
| 470 |
index.vue
|
| 472 |
```vue
|
| 473 |
<script lang="tsx">
|
| 474 |
export default {
|
| 475 |
functional: true,
|
| 476 |
render(h, c) {
|
| 477 |
return (<div>Content</div>);
|
| 478 |
}
|
| 479 |
}
|
| 480 |
</script>
|
| 481 |
```
|
| 483 |
Or if you want to use only tsx, just use the
`appendTsxSuffixTo`
option only:
|
| 485 |
```javascript
|
| 486 |
{ test: /\.ts$/, loader: 'ts-loader' }
|
| 487 |
{ test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/\.vue$/] } }
|
| 488 |
```
|
| 490 |
#### onlyCompileBundledFiles _(boolean) (default=false)_
|
| 492 |
The default behavior of ts-loader is to act as a drop-in replacement for the
`tsc`
command,
|
| 493 |
so it respects the
`include`
,
`files`
, and
`exclude`
options in your
`tsconfig.json`
, loading
|
| 494 |
any files specified by those options. The
`onlyCompileBundledFiles`
option modifies this behavior,
|
| 495 |
loading only those files that are actually bundled by webpack, as well as any
`.d.ts`
files included
|
| 496 |
by the
`tsconfig.json`
settings.
`.d.ts`
files are still included because they may be needed for
|
| 497 |
compilation without being explicitly imported, and therefore not picked up by webpack.
|
| 499 |
#### allowTsInNodeModules _(boolean) (default=false)_
|
| 501 |
By default, ts-loader will not compile
`.ts`
files in
`node_modules`
.
|
| 502 |
You should not need to recompile
`.ts`
files there, but if you really want to, use this option.
|
| 503 |
Note that this option acts as a
*whitelist*
- any modules you desire to import must be included in
|
| 504 |
the
`"files"`
or
`"include"`
block of your project's
`tsconfig.json`
.
|
| 506 |
See: [
https://github.com/Microsoft/TypeScript/issues/12358
](
https://github.com/Microsoft/TypeScript/issues/12358
)
|
| 508 |
```javascript
|
| 509 |
// in webpack.config.js
|
| 510 |
{
|
| 511 |
test: /\.ts$/,
|
| 512 |
loader: 'ts-loader',
|
| 513 |
options: { allowTsInNodeModules: true }
|
| 514 |
}
|
| 515 |
```
|
| 517 |
And in your
`tsconfig.json`
:
|
| 519 |
```json
|
| 520 |
{
|
| 521 |
"include": [
|
| 522 |
"node_modules/whitelisted_module.ts"
|
| 523 |
],
|
| 524 |
"files": [
|
| 525 |
"node_modules/my_module/whitelisted_file.ts"
|
| 526 |
]
|
| 527 |
}
|
| 528 |
```
|
| 530 |
#### context _(string) (default=undefined)_
|
| 532 |
If set, will parse the TypeScript configuration file with given
**absolute path**
as base path.
|
| 533 |
Per default the directory of the configuration file is used as base path. Relative paths in the configuration
|
| 534 |
file are resolved with respect to the base path when parsed. Option
`context`
allows to set option
|
| 535 |
`configFile`
to a path other than the project root (e.g. a NPM package), while the base path for
`ts-loader`
|
| 536 |
can remain the project root.
|
| 538 |
Keep in mind that
**not**
having a
`tsconfig.json`
in your project root can cause different behaviour between
`ts-loader`
and
`tsc`
.
|
| 539 |
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
|
| 540 |
referenced in option
`configFile`
. For more information please [
read the PR
](
https://github.com/TypeStrong/ts-loader/pull/681
) that
|
| 541 |
is the base and [
read the PR
](
https://github.com/TypeStrong/ts-loader/pull/688
) that contributed this option.
|
| 543 |
webpack:
|
| 545 |
```javascript
|
| 546 |
{
|
| 547 |
loader: require.resolve('ts-loader'),
|
| 548 |
options: {
|
| 549 |
context: __dirname,
|
| 550 |
configFile: require.resolve('ts-config-react-app')
|
| 551 |
}
|
| 552 |
}
|
| 553 |
```
|
| 555 |
Extending
`tsconfig.json`
:
|
| 557 |
```json
|
| 558 |
{ "extends": "./node_modules/ts-config-react-app/index" }
|
| 559 |
```
|
| 561 |
Note that changes in the extending file while not be respected by
`ts-loader`
. Its purpose is to satisfy the code editor.
|
| 563 |
#### experimentalFileCaching _(boolean) (default=true)_
|
| 565 |
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
](
https://github.com/TypeStrong/ts-loader/issues/825#issue-354725524
) with example).
|
| 566 |
In some cases it may produce performance degradation.
|
| 568 |
This flag enables caching for some FS-functions like
`fileExists`
,
`realpath`
and
`directoryExists`
for TypeScript compiler. Note that caches are cleared between compilations.
|
| 570 |
#### projectReferences _(boolean) (default=false)_
|
| 572 |
**TL;DR:**
Using project references currently requires building referenced projects outside of ts-loader. We don’t want to keep it that way, but we’re releasing what we’ve got now. To try it out, you’ll need to pass
`projectReferences: true`
to
`loaderOptions`
. You’ll also probably need to use TypeScript 3.1.1 or later (which, as of this writing, means
`typescript@next`
).
|
| 574 |
ts-loader has partial support for [
project references
](
https://www.typescriptlang.org/docs/handbook/project-references.html
) in that it will
_load_
dependent composite projects that are already built, but will not currently
_build/rebuild_
those upstream projects. The best way to explain exactly what this means is through an example. Say you have a project with a project reference pointing to the
`lib/`
directory:
|
| 576 |
```
|
| 577 |
tsconfig.json
|
| 578 |
app.ts
|
| 579 |
lib/
|
| 580 |
tsconfig.json
|
| 581 |
niftyUtil.ts
|
| 582 |
```
|
| 584 |
And we’ll assume that the root
`tsconfig.json`
has
`{ "references": { "path": "lib" } }`
, which means that any import of a file that’s part of the
`lib`
sub-project is treated as a reference to another project, not just a reference to a TypeScript file. Before discussing how ts-loader handles this, it’s helpful to review at a really basic level what
`tsc`
itself does here. If you were to run
`tsc`
on this tiny example project, the build would fail with the error:
|
| 586 |
```
|
| 587 |
error TS6305: Output file 'lib/niftyUtil.d.ts' has not been built from source file 'lib/niftyUtil.ts'.
|
| 588 |
```
|
| 590 |
Using project references actually instructs
`tsc`
_not_
to build anything that’s part of another project from source, but rather to look for any
`.d.ts`
and
`.js`
files that have already been generated from a previous build. Since we’ve never built the project in
`lib`
before, those files don’t exist, so building the root project fails. Still just thinking about how
`tsc`
works, there are two options to make the build succeed: either run
`tsc -p lib/tsconfig.json`
_first_
, or simply run
`tsc --build`
, which will figure out that
`lib`
hasn’t been built and build it first for you.
|
| 592 |
Ok, so how is that relevant to ts-loader? Because the best way to think about what ts-loader does with project references is that it acts like
`tsc`
, but
_not_
like
`tsc --build`
. If you run ts-loader on a project that’s using project references, and any upstream project hasn’t been built, you’ll get the exact same
`error TS6305`
that you would get with
`tsc`
. If you modify a source file in an upstream project and don’t rebuild that project,
`ts-loader`
won’t have any idea that you’ve changed anything—it will still be looking at the output from the last time you
_built_
that file.
|
| 594 |
**“Hey, don’t you think that sounds kind of useless and terrible?”**
Well, sort of. You can consider it a work-in-progress. It’s true that on its own, as of today, ts-loader doesn’t have everything you need to take advantage of project references in webpack. In practice, though,
_consuming_
upstream projects and
_building_
upstream projects are somewhat separate concerns. Building them will likely come in a future release. For background, see the [
original issue
](
https://github.com/TypeStrong/ts-loader/issues/815
).
|
| 596 |
**`outDir` Windows problemo.**
At the moment, composite projects built using the [
`outDir` compiler option
](
https://www.typescriptlang.org/docs/handbook/compiler-options.html
) cannot be consumed using ts-loader on Windows. If you try to, ts-loader throws a "has not been built from source file" error. We don't know why yet; it's possible there's a bug in
`tsc`
. It's more likely there's a bug in
`ts-loader`
. Hopefully it's going to get solved at some point. (Hey, maybe you're the one to solve it!) Either way, we didn't want to hold back from releasing. So if you're building on Windows then avoid building
`composite`
projects using
`outDir`
.
|
| 598 |
**TypeScript version compatibility.**
As a final caveat, [
this commit to TypeScript
](
https://github.com/Microsoft/TypeScript/commit/d519e3f21ec36274726c44dab25c9eb48e34953f
) is necessary for the
`include`
or
`exclude`
options of a project-referenced tsconfig file to work. It should be released in TypeScript 3.1.1 according to the tags. To use an earlier version of TypeScript, referenced project configuration files must specify
`files`
, and not
`include`
.
|
| 600 |
### Usage with webpack watch
|
| 602 |
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:
|
| 604 |
```javascript
|
| 605 |
plugins: [
|
| 606 |
new webpack.WatchIgnorePlugin([
|
| 607 |
/\.js$/,
|
| 608 |
/\.d\.ts$/
|
| 609 |
])
|
| 610 |
],
|
| 611 |
```
|
| 613 |
It's worth noting that use of the
`LoaderOptionsPlugin`
is [
only supposed to be a stopgap measure
](
https://webpack.js.org/plugins/loader-options-plugin/
). You may want to look at removing it entirely.
|
| 615 |
### Hot Module replacement
|
| 617 |
To enable
`webpack-dev-server`
HMR, you need to follow the official [
webpack HMR guide
](
https://webpack.js.org/guides/hot-module-replacement/
), then tweak a few config options for
`ts-loader`
. The required configuration is as follows:
|
| 619 |
1.
Set
`transpileOnly`
to
`true`
(see [
transpileOnly
](
#transpileonly-boolean-defaultfalse
) for config details and recommendations above).
|
| 620 |
2.
Inside your HMR acceptance callback function, you must re-require the module that was replaced.
|
| 622 |
For a boilerplate HMR project using React, check out the [
react-hot-boilerplate example
](
./examples/react-hot-boilerplate/
).
|
| 624 |
For a minimal HMR TypeScript setup, go to the [
hot-module-replacement example
](
./examples/hot-module-replacement/
).
|
| 626 |
## Contributing
|
推荐文章