\n
\n This is the TypeScript loader for webpack.\n
\n
\n Installation\n ·\n Report Bug\n ·\n Request Feature\n
hello {{msg}}
\n\n```\n\nWe can handle `.tsx` by quite similar way:\n\nwebpack.config.js:\n\n```javascript\nmodule.exports = {\n entry: './index.vue',\n output: { filename: 'bundle.js' },\n resolve: {\n extensions: ['.ts', '.tsx', '.vue', '.vuex']\n },\n module: {\n rules: [\n { test: /\\.vue$/, loader: 'vue-loader',\n options: {\n loaders: {\n ts: 'ts-loader',\n tsx: 'babel-loader!ts-loader',\n }\n }\n },\n { test: /\\.ts$/, loader: 'ts-loader', options: { appendTsSuffixTo: [/TS\\.vue$/] } }\n { test: /\\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/TSX\\.vue$/] } }\n ]\n }\n}\n```\n\ntsconfig.json (set `jsx` option to `preserve` to let babel handle jsx)\n\n```json\n{\n \"compilerOptions\": {\n \"jsx\": \"preserve\"\n }\n}\n```\n\nindex.vue\n\n```vue\n\n```\n\nOr if you want to use only tsx, just use the `appendTsxSuffixTo` option only:\n\n```javascript\n { test: /\\.ts$/, loader: 'ts-loader' }\n { test: /\\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/\\.vue$/] } }\n```\n\n#### onlyCompileBundledFiles\n| Type | Default Value |\n|------|--------------|\n| `boolean` | `false`|\n\nThe default behavior of `ts-loader` is to act as a drop-in replacement for the `tsc` command,\nso it respects the `include`, `files`, and `exclude` options in your `tsconfig.json`, loading\nany files specified by those options. The `onlyCompileBundledFiles` option modifies this behavior,\nloading only those files that are actually bundled by webpack, as well as any `.d.ts` files included\nby the `tsconfig.json` settings. `.d.ts` files are still included because they may be needed for\ncompilation without being explicitly imported, and therefore not picked up by webpack.\n\n#### useCaseSensitiveFileNames\n| Type | Default Value |\n|------|--------------|\n| `boolean` | determined by typescript based on platform |\n\nThe default behavior of `ts-loader` is to act as a drop-in replacement for the `tsc` command,\nso it respects the `useCaseSensitiveFileNames` set internally by typescript. The `useCaseSensitiveFileNames` option modifies this behavior,\nby 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.\n\n#### allowTsInNodeModules\n| Type | Default Value |\n|------|--------------|\n| `boolean` | `false`|\n\nBy default, `ts-loader` will not compile `.ts` files in `node_modules`.\nYou should not need to recompile `.ts` files there, but if you really want to, use this option.\nNote that this option acts as a *whitelist* - any modules you desire to import must be included in\nthe `\"files\"` or `\"include\"` block of your project's `tsconfig.json`.\n\nSee: [https://github.com/Microsoft/TypeScript/issues/12358](https://github.com/Microsoft/TypeScript/issues/12358)\n\n```javascript\n // in webpack.config.js\n {\n test: /\\.ts$/,\n loader: 'ts-loader',\n options: { allowTsInNodeModules: true }\n }\n```\n\nAnd in your `tsconfig.json`:\n\n```json\n {\n \"include\": [\n \"node_modules/whitelisted_module.ts\"\n ],\n \"files\": [\n \"node_modules/my_module/whitelisted_file.ts\"\n ]\n }\n```\n\n#### context\n| Type | Default Value |\n|------|--------------|\n| `string` | `undefined`|\n\nIf set, will parse the TypeScript configuration file with given **absolute path** as base path.\nPer default the directory of the configuration file is used as base path. Relative paths in the configuration\nfile are resolved with respect to the base path when parsed. Option `context` allows to set option\n`configFile` to a path other than the project root (e.g. a NPM package), while the base path for `ts-loader`\ncan remain the project root.\n\nKeep in mind that **not** having a `tsconfig.json` in your project root can cause different behaviour between `ts-loader` and `tsc`.\nWhen 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\nreferenced in option `configFile`. For more information please [read the PR](https://github.com/TypeStrong/ts-loader/pull/681) that\nis the base and [read the PR](https://github.com/TypeStrong/ts-loader/pull/688) that contributed this option.\n\nwebpack:\n\n```javascript\n{\n loader: require.resolve('ts-loader'),\n options: {\n context: __dirname,\n configFile: require.resolve('ts-config-react-app')\n }\n}\n```\n\nExtending `tsconfig.json`:\n\n```json\n{ \"extends\": \"./node_modules/ts-config-react-app/index\" }\n```\n\nNote that changes in the extending file while not be respected by `ts-loader`. Its purpose is to satisfy the code editor.\n\n#### experimentalFileCaching\n| Type | Default Value |\n|------|--------------|\n| `boolean` | `true`|\n\nBy 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).\nIn some cases it may produce performance degradation.\n\nThis flag enables caching for some FS-functions like `fileExists`, `realpath` and `directoryExists` for TypeScript compiler. Note that caches are cleared between compilations.\n\n#### projectReferences\n| Type | Default Value |\n|------|--------------|\n| `boolean` | `false`|\n\nts-loader has opt-in support for [project references](https://www.typescriptlang.org/docs/handbook/project-references.html). 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.\n\nIn 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](REFERENCES.md) and the example code in the examples which can be found [here](examples/project-references-example/).\n\n### Usage with webpack watch\n\nBecause 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:\n\n```javascript\n// for webpack 4\n plugins: [\n new webpack.WatchIgnorePlugin([\n /\\.js$/,\n /\\.d\\.[cm]?ts$/\n ])\n ],\n\n// for webpack 5\nplugins: [\n new webpack.WatchIgnorePlugin({\n paths:[\n /\\.js$/,\n /\\.d\\.[cm]ts$/\n ]})\n],\n```\n\nIt'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.\n\n### Hot Module replacement\n\nWe do not support HMR as we did not yet work out a reliable way how to set it up.\n\nIf you want to give `webpack-dev-server` HMR a try, follow the official [webpack HMR guide](https://webpack.js.org/guides/hot-module-replacement/), then tweak a few config options for `ts-loader`:\n\n1. Set `transpileOnly` to `true` (see [transpileOnly](#transpileonly) for config details and recommendations above).\n2. Inside your HMR acceptance callback function, maybe re-require the module that was replaced.\n\n## Contributing\n\nThis is your TypeScript loader! We want you to help make it even better. Please feel free to contribute; see the [contributor's guide](CONTRIBUTING.md) to get started.\n\n## History\n\n`ts-loader` was started by [James Brantly](https://github.com/jbrantly), since 2016 [John Reilly](https://github.com/johnnyreilly) has been taking good care of it. If you're interested, you can [read more about how that came to pass](https://johnnyreilly.com/but-you-cant-die-i-love-you-ts-loader).\n\n## License\n\nMIT License\n","_attachments":{},"homepage":"https://github.com/TypeStrong/ts-loader","bugs":{"url":"https://github.com/TypeStrong/ts-loader/issues"},"license":"MIT"}