fork-ts-checker-webpack-plugin

What is fork-ts-checker-webpack-plugin?

The fork-ts-checker-webpack-plugin is a plugin for webpack that runs TypeScript type checking on a separate process. This allows you to get type checking results while webpack compiles your code, improving build speed by utilizing multiple CPU cores. It also integrates with ESLint to provide linting for both TypeScript and JavaScript files.

What are fork-ts-checker-webpack-plugin's main functionalities?

TypeScript Type Checking

This feature runs TypeScript type checking in a separate process to speed up the webpack build.

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  plugins: [new ForkTsCheckerWebpackPlugin()],
};

ESLint Integration

This feature allows the plugin to run ESLint on your code in parallel with the TypeScript type checker.

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  plugins: [
    new ForkTsCheckerWebpackPlugin({
      eslint: {
        files: './src/**/*.{ts,tsx,js,jsx}'
      }
    })
  ],
};

Asynchronous Reporting

This feature provides asynchronous reporting of type checking and linting results, so they do not block webpack's compilation process.

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const webpack = require('webpack');

const compiler = webpack({
  // ...webpack configuration
  plugins: [new ForkTsCheckerWebpackPlugin()],
});

compiler.run((error, stats) => {
  // ...handle webpack build result
});

Other packages similar to fork-ts-checker-webpack-plugin

ts-loader

ts-loader is a TypeScript loader for webpack. It is responsible for compiling TypeScript files to JavaScript. Unlike fork-ts-checker-webpack-plugin, ts-loader does the type checking in the main compilation process, which can be slower for large projects.

awesome-typescript-loader

awesome-typescript-loader is another TypeScript loader for webpack. Similar to ts-loader, it provides compilation of TypeScript files. It also offers features like Babel integration and can use a separate process for type checking, but it is not as actively maintained as fork-ts-checker-webpack-plugin.

eslint-webpack-plugin

eslint-webpack-plugin is a plugin for webpack that provides linting functionality. It integrates ESLint into the webpack build process. While it does not offer TypeScript type checking, it serves a similar purpose for linting as fork-ts-checker-webpack-plugin does when the ESLint integration is enabled.

README

Fork TS Checker Webpack Plugin

Webpack plugin that runs typescript type checker on a separate process.

Installation

This plugin requires minimum webpack 2, typescript 2.1 and optionally tslint 5.0

npm install --save-dev fork-ts-checker-webpack-plugin

Basic webpack config (with ts-loader)

var ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

var webpackConfig = {
  context: __dirname, // to automatically find tsconfig.json
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'ts-loader',
        options: {
          // disable type checker - we will use it in fork plugin
          transpileOnly: true 
        }
      }
    ]
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin()
  ]
};

Motivation

There is already similar solution - awesome-typescript-loader. You can add CheckerPlugin and delegate checker to the separate process. The problem with awesome-typescript-loader was that, in our case, it was a lot slower than ts-loader on an incremental build (~20s vs ~3s). Secondly, we use tslint and we wanted to run this, along with type checker, in a separate process. This is why we've created this plugin. To provide better performance, plugin reuses Abstract Syntax Trees between compilations and shares these trees with tslint. It can be scaled with a multi-process mode to utilize maximum CPU power.

Modules resolution

It's very important to be aware that this plugin uses typescript's, not webpack's modules resolution. It means that you have to setup tsconfig.json correctly. For example if you set files: ['./src/someFile.ts'] in tsconfig.json, this plugin will check only someFile.ts for semantic errors. It's because of performance. The goal of this plugin is to be as fast as possible. With typescript's module resolution we don't have to wait for webpack to compile files (which traverses dependency graph during compilation) - we have a full list of files from the begin.

To debug typescript's modules resolution, you can use tsc --traceResolution command.

TSLint

If you have installed tslint, you can enable it by setting tslint: true or tslint: './path/to/tslint.json'. We recommend changing defaultSeverity to a "warning" in tslint.json file. It helps to distinguish lints from typescript's diagnostics.

Options

• tsconfig string: Path to tsconfig.json file. Default: path.resolve(compiler.options.context, './tsconfig.json').

• tslint string | true: Path to tslint.json file or true. If true, uses path.resolve(compiler.options.context, './tslint.json'). Default: undefined.

• watch string | string[]: Directories or files to watch by service. Not necessary but improves performance (reduces number of fs.stat calls).

• ignoreDiagnostics number[]: List of typescript diagnostic codes to ignore.

• ignoreLints string[]: List of tslint rule names to ignore.

• colors boolean: If false, disables built-in colors in logger messages. Default: true.

• logger object: Logger instance. It should be object that implements method: error, warn, info. Default: console.

• silent boolean: If true, logger will not be used. Default: false.

• memoryLimit number: Memory limit for service process in MB. If service exits with allocation failed error, increase this number. Default: 2048.

• workers number: You can split type checking to a few workers to speed-up increment build. Be careful - if you don't want to increase build time, you should keep free 1 core for build and 1 core for a system (for example system with 4 CPUs should use max 2 workers). Second thing - node doesn't share memory between workers - keep in mind that memory usage will increase. Be aware that in some scenarios increasing workers number can increase checking time. Default: ForkTsCheckerWebpackPlugin.ONE_CPU.

Pre-computed consts:

• ForkTsCheckerWebpackPlugin.ONE_CPU - always use one CPU
• ForkTsCheckerWebpackPlugin.ALL_CPUS - always use all CPUs (will increase build time)
• ForkTsCheckerWebpackPlugin.ONE_CPU_FREE - leave only one CPU for build (probably will increase build time)
• ForkTsCheckerWebpackPlugin.TWO_CPUS_FREE - recommended - leave two CPUs free (one for build, one for system)

Plugin Hooks

This plugin provides some custom webpack hooks (all are sync):

Event name	Description	Params
fork-ts-checker-cancel	Cancellation has been requested	cancellationToken
fork-ts-checker-waiting	Waiting for results	hasTsLint
fork-ts-checker-service-start	Service will be started	tsconfigPath, tslintPath, watchPaths, workersNumber, memoryLimit
fork-ts-checker-service-start-error	Cannot start service	error
fork-ts-checker-service-out-of-memory	Service is out of memory	-
fork-ts-checker-receive	Plugin receives diagnostics and lints from service	diagnostics, lints
fork-ts-checker-emit	Service will add errors and warnings to webpack compilation ('build' mode)	diagnostics, lints, elapsed
fork-ts-checker-done	Service finished type checking and webpack finished compilation ('watch' mode)	diagnostics, lints, elapsed

License

MIT

Changelog

v0.2.3

• Add support for webpack 3 as peerDependency