TS-loader: TypeScript Loader for Webpack

TypeScript loader for webpack

ts-loader

This is the TypeScript loader for webpack.

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

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 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: microsoft/TypeScript#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.

Download Details:

Author: TypeStrong
Source Code: https://github.com/TypeStrong/ts-loader 
License: MIT license

#typescript #webpack #loader 

What is GEEK

Buddha Community

TS-loader: TypeScript Loader for Webpack

TypeScript loader for webpack

ts-loader

This is the TypeScript loader for webpack.

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

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 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: microsoft/TypeScript#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.

Download Details:

Author: TypeStrong
Source Code: https://github.com/TypeStrong/ts-loader 
License: MIT license

#typescript #webpack #loader 

The Definitive Guide to TypeScript & Possibly The Best TypeScript Book

TypeScript Deep Dive

I've been looking at the issues that turn up commonly when people start using TypeScript. This is based on the lessons from Stack Overflow / DefinitelyTyped and general engagement with the TypeScript community. You can follow for updates and don't forget to ★ on GitHub 🌹

Reviews

• Thanks for the wonderful book. Learned a lot from it. (link)
• Its probably the Best TypeScript book out there. Good Job (link)
• Love how precise and clear the examples and explanations are! (link)
• For the low, low price of free, you get pages of pure awesomeness. Chock full of source code examples and clear, concise explanations, TypeScript Deep Dive will help you learn TypeScript development. (link)
• Just a big thank you! Best TypeScript 2 detailed explanation! (link)
• This gitbook got my project going pronto. Fluent easy read 5 stars. (link)
• I recommend the online #typescript book by @basarat you'll love it.(link)
• I've always found this by @basarat really helpful. (link)
• We must highlight TypeScript Deep Dive, an open source book.(link)
• Great online resource for learning. (link)
• Thank you for putting this book together, and for all your hard work within the TypeScript community. (link)
• TypeScript Deep Dive is one of the best technical texts I've read in a while. (link)
• Thanks @basarat for the TypeScript Deep Dive Book. Help me a lot with my first TypeScript project. (link)
• Thanks to @basarat for this great #typescript learning resource. (link)
• Guyz excellent book on Typescript(@typescriptlang) by @basarat (link)
• Leaning on the legendary @basarat's "TypeScript Deep Dive" book heavily at the moment (link)
• numTimesPointedPeopleToBasaratsTypeScriptBook++; (link)
• A book not only for typescript, a good one for deeper JavaScript knowledge as well. link
• In my new job, we're using @typescriptlang, which I am new to. This is insanely helpful huge thanks, @basarat! link
• Thank you for writing TypeScript Deep Dive. I have learned so much. link
• Loving @basarat's @typescriptlang online book basarat.gitbooks.io/typescript/# loaded with great recipes! link
• Microsoft doc is great already, but if want to "dig deeper" into TypeScript I find this book of great value link
• Thanks, this is a great book 🤓🤓 link
• Deep dive to typescript is awesome in so many levels. i find it very insightful. Thanks link
• @basarat's intro to @typescriptlang is still one of the best going (if not THE best) link
•  
• This is sweet! So many #typescript goodies! link

Get Started

If you are here to read the book online get started.

Translations

Book is completely free so you can copy paste whatever you want without requiring permission. If you have a translation you want me to link here. Send a PR.

• Filipino
• Italian
• Chinese
• Russian
• Portuguese
• Japanese
• Spanish
• Korean
• French
• Polish
• Thai

Other Options

You can also download one of the Epub, Mobi, or PDF formats from the actions tab by clicking on the latest build run. You will find the files in the artifacts section.

Special Thanks

All the amazing contributors 🌹

Share

Share URL: https://basarat.gitbook.io/typescript/

Author: Basarat
Source Code: https://github.com/basarat/typescript-book/ 
License: View license

#typescript #opensource 

istanbul-loader: A Code Coverage-instrumenting Webpack Loader

istanbul-loader

This is a webpack loader that uses istanbul-lib-instrument to add code coverage instrumentation to JavaScript files.

Installation

Install with

npm install @theintern/istanbul-loader --save-dev

Usage

Install the loader in a project and add an entry for it to the project's webpack.config:

module: {
    rules: [
        {
            test: /src\/.*\.ts$/,
            use: '@theintern/istanbul-loader'
        },
        ...
    ]
}

Note that the istanbul-loader should be run after transpilers such as TypeScript. This means that it should come before transpilers in a loader list, or use enforce: 'post':

rules: [
    {
        test: /src\/.(\.ts$/,
        use: [ '@theintern/istanbul-loader', 'ts-node' ]
    },
    ...
]

or

rules: [
    {
        test: /src\/.(\.ts$/,
        use: '@theintern/istanbul-loader',
        enforce: 'post'
    },
    ...
]

Configuration

The rule test should only match source files, not all .ts or .js files, so as not to instrument tests or support files.

Options can be passed using the standard webpack options property:

rules: [
    {
        test: /src\/.(\.ts$/,
        use: {
            loader: '@theintern/istanbul-loader',
            options: { config: 'tests/intern.json' }
        }
    },
    ...
]

Currently the only option used by the loader is 'config', which should point to an Intern config file. The loader will use values for coverageVariable and instrumenterOptions from the Intern config, if present.

Download Details: 

Author: Theintern
Source Code: https://github.com/theintern/istanbul-loader 
License: View license

#typescript #loader #webpack 

Awesome TypeScript Loader for Webpack

TypeScript loader for Webpack 

See also:

1. tsdoc.io — TypeScript documentation portal (backed by tygen).

Installation

npm install awesome-typescript-loader --save-dev

Performance issues

Please note that ATL works the same way as a TypeScript compiler as much as possible. So please be careful with your files/exclude/include sections.

ADVICE: Turn on useCache option.

ADVICE: Typically you want your files section to include only entry points.

ADVICE: The loader works faster if you use isolatedModules or forceIsolatedModules options.

ADVICE: The loader works faster if you will use reportFiles to restrict checking scope.

ADVICE: Use the loader together with hard-source-webpack-plugin

The world is changing, other solutions are evolving and ATL may work slower for some workloads. Feel free to try ts-loader with HappyPack or thread-loader and hard-source-webpack-plugin.

Differences between ts-loader

awesome-typescript-loader loader was created mostly to speed-up compilation in my own projects. Some of them are quite big and I wanted to have full control on how my files are compiled. There are two major points:

atl has first-class integration with Babel and enables caching possibilities. This can be useful for those who use Typescript with Babel. When useBabel and useCache flags are enabled, typescript's emit will be transpiled with Babel and cached. So next time if source file (+environment) has the same checksum we can totally skip typescript's and babel's transpiling. This significantly reduces build time in this scenario.

atl is able to fork type-checker and emitter to a separate process, which also speeds-up some development scenarios (e.g. react with react-hot-loader) So your webpack compilation will end earlier and you can explore compiled version in your browser while your files are typechecked.

Configuration

1. Add .ts as a resolvable extension.
2. Configure all files with a .ts extension to be handled by awesome-typescript-loader.

webpack.config.js

// `CheckerPlugin` is optional. Use it if you want async error reporting.
// We need this plugin to detect a `--watch` mode. It may be removed later
// after https://github.com/webpack/webpack/issues/3460 will be resolved.
const { CheckerPlugin } = require('awesome-typescript-loader')

module.exports = {

  // Currently we need to add '.ts' to the resolve.extensions array.
  resolve: {
    extensions: ['.ts', '.tsx', '.js', '.jsx']
  },

  // Source maps support ('inline-source-map' also works)
  devtool: 'source-map',

  // Add the loader for .ts files.
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'awesome-typescript-loader'
      }
    ]
  },
  plugins: [
      new CheckerPlugin()
  ]
};

After that, you will be able to build TypeScript files with webpack.

NodeJS versions

The loader supports NodeJS 4 and newer.

tsconfig.json

You can use the tsconfig.json file to configure your compiler and loader:

{
    "compilerOptions": {
        "noImplicitAny": true,
        "removeComments": true
    },
    "awesomeTypescriptLoaderOptions": {
        /* ... */
    }
}

Supported TypeScript

awesome-typescript-loader@2.x aims to support only typescript@2.x and webpack@2x, if you need old compilers please use 1.x or 0.x versions.

Advanced path resolution in TypeScript 2.0

If you want to use new paths and baseUrl feature of TS 2.0 please include TsConfigPathsPlugin. This feature is available only for webpack@2.1.

const { TsConfigPathsPlugin } = require('awesome-typescript-loader');

resolve: {
    plugins: [
        new TsConfigPathsPlugin(/* { configFileName, compiler } */)
    ]
}

Loader options

silent (boolean) (default=false)

No logging from the checker. Please note that this option disables async error reporting because this option bans console.log() usage.

compiler (string) (default='typescript')

Allows use of TypeScript compilers other than the official one. Must be set to the NPM name of the compiler, e.g. ntypescript or the path to a package folder. Note that the compiler must be installed in your project. You can also use nightly versions.

useTranspileModule (boolean) (default=false)*

Use fast transpileModule emit mode. Disables automatically when you set compilerOption declaration: true (reference).

instance (string) (default='at-loader')

Allows the use of several TypeScript compilers with different settings in one app. Override instance to initialize another instance.

configFileName (string) (default='tsconfig.json')

Specifies the path to a TS config file. This is useful when you have multiple config files. This setting is useless inside a TS config file.

transpileOnly (boolean)

Use this setting to disable type checking, enabling this will nullify the CheckerPlugin usage in your webpack configuration.

errorsAsWarnings (boolean)

Emit all typescript errors as warnings.

forceIsolatedModules (boolean)

Use this setting to disable dependent module recompilation.

ignoreDiagnostics (number[]) (default=[])

You can squelch certain TypeScript errors by specifying an array of diagnostic codes to ignore. For example, you can transpile stage 1 properties from *.js using "ignoreDiagnostics": [8014].

useBabel (boolean) (default=false)

Invoke Babel to transpile files. Useful with ES6 target. Please see useCache option which can improve warm-up time.

If you're using babelOptions, anything in .babelrc will take precedence. This breaks expected usage for scenarios where you need two sets of Babel configs (example: one for Webpack, one for your build tools).

You may want to "babelrc": false to disable .babelrc if you don't want it:

{
    "useBabel": true,
    "babelOptions": {
        "babelrc": false, /* Important line */
        "presets": [
            ["@babel/preset-env", { "targets": "last 2 versions, ie 11", "modules": false }]
        ]
    },
    "babelCore": "@babel/core", // needed for Babel v7
}

babelCore (string) (default=undefined)

Override the path used to find babel-core. Useful if node_modules is installed in a non-standard place or webpack is being invoked from a directory not at the root of the project.

For Babel 7, this should be set to "@babel/core".

babelOptions (object) (default=null)

Use this option to pass some options to Babel (e.g. presets). Please note that .babelrc file is more universal way to do this.

useCache (boolean) (default=false)

Use internal file cache. This is useful with Babel, when processing takes a long time to complete. Improves warm-up time.

usePrecompiledFiles (boolean) (default=false)

Use pre-compiled files if any. Files must be named as {filename}.js and {filename}.map.

cacheDirectory (string) (default='.awcache')

Directory where cache is stored.

reportFiles (string[])

Specify globs to report file diagnostics. ALL OTHER ERRORS WILL NOT BE REPORTED. Example:

reportFiles: [
    "src/**/*.{ts,tsx}"
]

getCustomTransformers (string | ((program: ts.Program) => ts.CustomTransformers | undefined)) (default=undefined)

Provide custom transformers, TypeScript 2.4.1+. Example:

const styledComponentsTransformer = require('typescript-plugin-styled-components').default;
const keysTransformer = require('ts-transformer-keys/transformer').default;

// ...
rules: [
    {
        test: /\.tsx?$/,
        loader: 'awesome-typescript-loader',
        options: {
            // ... other loader's options
            getCustomTransformers: program => ({
                before: [
                    styledComponentsTransformer(),
                    keysTransformer(program)
                ]
            })
        }
    }
]

Compiler options

You can pass compiler options inside the loader query string or in a TS config file.

Author: S-panferov
Source Code: https://github.com/s-panferov/awesome-typescript-loader 
License: View license

#es6 #javascript #typescript #webpack 

Webpack: A Bundler for Javascript and Friends

webpack

Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

Install

Install with npm:

npm install --save-dev webpack

Install with yarn:

yarn add webpack --dev

Introduction

Webpack is a bundler for modules. The main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

TL;DR

• Bundles ES Modules, CommonJS, and AMD modules (even combined).
• Can create a single bundle or multiple chunks that are asynchronously loaded at runtime (to reduce initial loading time).
• Dependencies are resolved during compilation, reducing the runtime size.
• Loaders can preprocess files while compiling, e.g. TypeScript to JavaScript, Handlebars strings to compiled functions, images to Base64, etc.
• Highly modular plugin system to do whatever else your application requires.

Get Started

Check out webpack's quick Get Started guide and the other guides.

Browser Compatibility

Webpack supports all browsers that are ES5-compliant (IE8 and below are not supported). Webpack also needs Promise for import() and require.ensure(). If you want to support older browsers, you will need to load a polyfill before using these expressions.

Concepts

Plugins

Webpack has a rich plugin interface. Most of the features within webpack itself use this plugin interface. This makes webpack very flexible.

Name	Status	Install Size	Description
[mini-css-extract-plugin][mini-css]	![mini-css-npm]	![mini-css-size]	Extracts CSS into separate files. It creates a CSS file per JS file which contains CSS.
[compression-webpack-plugin][compression]	![compression-npm]	![compression-size]	Prepares compressed versions of assets to serve them with Content-Encoding
[html-webpack-plugin][html-plugin]	![html-plugin-npm]	![html-plugin-size]	Simplifies creation of HTML files (index.html) to serve your bundles

Loaders

Webpack enables the use of loaders to preprocess files. This allows you to bundle any static resource way beyond JavaScript. You can easily write your own loaders using Node.js.

Loaders are activated by using loadername! prefixes in require() statements, or are automatically applied via regex from your webpack configuration.

Files

Name	Status	Install Size	Description
[val-loader][val]	![val-npm]	![val-size]	Executes code as module and considers exports as JS code

JSON

Name	Status	Install Size	Description
	![cson-npm]	![cson-size]	Loads and transpiles a CSON file

Transpiling

Name	Status	Install Size	Description
	![babel-npm]	![babel-size]	Loads ES2015+ code and transpiles to ES5 using Babel
	![type-npm]	![type-size]	Loads TypeScript like JavaScript
	![coffee-npm]	![coffee-size]	Loads CoffeeScript like JavaScript

Templating

Name	Status	Install Size	Description
	![html-npm]	![html-size]	Exports HTML as string, requires references to static resources
	![pug-npm]	![pug-size]	Loads Pug templates and returns a function
	![md-npm]	![md-size]	Compiles Markdown to HTML
	![posthtml-npm]	![posthtml-size]	Loads and transforms a HTML file using PostHTML
	![hbs-npm]	![hbs-size]	Compiles Handlebars to HTML

Styling

Name	Status	Install Size	Description
<style>	![style-npm]	![style-size]	Add exports of a module as style to DOM
	![css-npm]	![css-size]	Loads CSS file with resolved imports and returns CSS code
	![less-npm]	![less-size]	Loads and compiles a LESS file
	![sass-npm]	![sass-size]	Loads and compiles a Sass/SCSS file
	![stylus-npm]	![stylus-size]	Loads and compiles a Stylus file
	![postcss-npm]	![postcss-size]	Loads and transforms a CSS/SSS file using PostCSS

Frameworks

Name	Status	Install Size	Description
	![vue-npm]	![vue-size]	Loads and compiles Vue Components
	![polymer-npm]	![polymer-size]	Process HTML & CSS with preprocessor of choice and require() Web Components like first-class modules
	![angular-npm]	![angular-size]	Loads and compiles Angular 2 Components
	![riot-npm]	![riot-size]	Riot official webpack loader

Performance

Webpack uses async I/O and has multiple caching levels. This makes webpack fast and incredibly fast on incremental compilations.

Module Formats

Webpack supports ES2015+, CommonJS and AMD modules out of the box. It performs clever static analysis on the AST of your code. It even has an evaluation engine to evaluate simple expressions. This allows you to support most existing libraries out of the box.

Code Splitting

Webpack allows you to split your codebase into multiple chunks. Chunks are loaded asynchronously at runtime. This reduces the initial loading time.

Optimizations

Webpack can do many optimizations to reduce the output size of your JavaScript by deduplicating frequently used modules, minifying, and giving you full control of what is loaded initially and what is loaded at runtime through code splitting. It can also make your code chunks cache friendly by using hashes.

Contributing

We want contributing to webpack to be fun, enjoyable, and educational for anyone, and everyone. We have a vibrant ecosystem that spans beyond this single repo. We welcome you to check out any of the repositories in our organization or webpack-contrib organization which houses all of our loaders and plugins.

Contributions go far beyond pull requests and commits. Although we love giving you the opportunity to put your stamp on webpack, we also are thrilled to receive a variety of other contributions including:

• Documentation updates, enhancements, designs, or bugfixes
• Spelling or grammar fixes
• README.md corrections or redesigns
• Adding unit, or functional tests
• Triaging GitHub issues -- especially determining whether an issue still persists or is reproducible.
• Searching #webpack on twitter and helping someone else who needs help
• Teaching others how to contribute to one of the many webpack's repos!
• Blogging, speaking about, or creating tutorials about one of webpack's many features.
• Helping others in our webpack gitter channel.

To get started have a look at our documentation on contributing.

If you are worried or don't know where to start, you can always reach out to Sean Larkin (@TheLarkInn) on Twitter or simply submit an issue and a maintainer can help give you guidance!

We have also started a series on our Medium Publication called The Contributor's Guide to webpack. We welcome you to read it and post any questions or responses if you still need help.

Looking to speak about webpack? We'd love to review your talk abstract/CFP! You can email it to webpack [at] opencollective [dot] com and we can give pointers or tips!!!

Creating your own plugins and loaders

If you create a loader or plugin, we would <3 for you to open source it, and put it on npm. We follow the x-loader, x-webpack-plugin naming convention.

Support

We consider webpack to be a low-level tool used not only individually but also layered beneath other awesome tools. Because of its flexibility, webpack isn't always the easiest entry-level solution, however we do believe it is the most powerful. That said, we're always looking for ways to improve and simplify the tool without compromising functionality. If you have any ideas on ways to accomplish this, we're all ears!

If you're just getting started, take a look at our new docs and concepts page. This has a high level overview that is great for beginners!!

Looking for webpack 1 docs? Please check out the old wiki, but note that this deprecated version is no longer supported.

If you want to discuss something or just need help, here is our Gitter room where there are always individuals looking to help out!

If you are still having difficulty, we would love for you to post a question to StackOverflow with the webpack tag. It is much easier to answer questions that include your webpack.config.js and relevant files! So if you can provide them, we'd be extremely grateful (and more likely to help you find the answer!)

If you are twitter savvy you can tweet #webpack with your question and someone should be able to reach out and help also.

If you have discovered a 🐜 or have a feature suggestion, feel free to create an issue on Github.

Sponsoring

Most of the core team members, webpack contributors and contributors in the ecosystem do this open source work in their free time. If you use webpack for a serious task, and you'd like us to invest more time on it, please donate. This project increases your income/productivity too. It makes development and applications faster and it reduces the required bandwidth.

This is how we use the donations:

• Allow the core team to work on webpack
• Thank contributors if they invested a large amount of time in contributing
• Support projects in the ecosystem that are of great value for users
• Support projects that are voted most (work in progress)
• Infrastructure cost
• Fees for money handling

Author: Webpack
Source Code: https://github.com/webpack/webpack 
License: MIT License

#webpack #javascript