fork-ts-checker-webpack-plugin
Advanced tools
Runs typescript type checker and linter on separate process.
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.
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
});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 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 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.
Webpack plugin that runs typescript type checker on a separate process.
This plugin requires minimum webpack 2.3, typescript 2.1 and optionally tslint 4.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()
]
};
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.
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.
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.
tsconfig string:
Path to tsconfig.json file. Default: path.resolve(compiler.options.context, './tsconfig.json').
compilerOptions object:
Allows overriding TypeScript options. Should be specified in the same format as you would do for the compilerOptions property in tsconfig.json. Default: {}.
tslint string | true | undefined:
string, path to tslint.json file to check source files against.true, path to tslint.json file will be computed with respect to currently checked file, just like TSLint
CLI would do. Suppose you have a project:
./
tslint.json
src/
file.ts
anotherFile.ts
lib/
tslint.json
someHelperFile.ts
src/file.ts and src/anotherFile.ts would be checked against root tslint.json, and
src/lib/someHelperFile.ts would be checked against src/lib/tslint.json.Default: undefined.
tslintAutoFix boolean :
Passes on --fix flag while running tslint to auto fix linting errors. Default: false.
watch string | string[]:
Directories or files to watch by service. Not necessary but improves performance (reduces number of fs.stat calls).
async boolean:
True by default - async: false can block webpack's emit to wait for type checker/linter and to add errors to the webpack's compilation.
We recommend to set this to false in projects where type checking is faster than webpack's build - it's better for integration with other plugins. Another scenario where you might want to set this to false is if you use the overlay functionality of webpack-dev-server.
ignoreDiagnostics number[]:
List of typescript diagnostic codes to ignore.
ignoreLints string[]:
List of tslint rule names to ignore.
ignoreLintWarnings boolean:
If true, will ignore all lint warnings.
reportFiles string[]:
Only report errors on files matching these glob patterns. This can be useful when certain types definitions have errors that are not fatal to your application. Default: [].
// in webpack.config.js
new ForkTsCheckerWebpackPlugin({ reportFiles: ['src/**/*.{ts,tsx}', '!src/skip.ts'] })
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.
formatter 'default' | 'codeframe' | ((message: NormalizedMessage, useColors: boolean) => string):
Formatter for diagnostics and lints. By default uses default formatter. You can also pass your own formatter as a function
(see src/NormalizedMessage.js and src/formatter/ for api reference).
formatterOptions object:
Options passed to formatters (currently only codeframe - see available options)
silent boolean:
If true, logger will not be used. Default: false.
checkSyntacticErrors boolean:
This option is useful if you're using ts-loader in happyPackMode with HappyPack or thread-loader to parallelise your builds. If true it 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. This is because when ts-loader is used in transpileOnly mode, ts-loader will still report syntactic errors. When used in happyPackMode it does not. 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.
vue boolean:
If true, the linter and compiler will process VueJs single-file-component (.vue) files. See the
Vue section further down for information on how to correctly setup your project.
useTypescriptIncrementalApi boolean:
If true, the plugin will use incremental compilation API introduced in typescript 2.7. In this mode you can only have 1
worker, but if the changes in your code are small (like you normally have when you work in 'watch' mode), the compilation
may be much faster, even compared to multi-threaded compilation. Defaults to true when working with typescript 3+ and false when below 3. The default can be overridden by directly specifying a value.
measureCompilationTime boolean:
If true, the plugin will measure the time spent inside the compilation code. This may be useful to compare modes,
especially if there are other loaders/plugins involved in the compilation. requires node 8+
typescript string:
If supplied this is a custom path where typescript can be found. Defaults to require.resolve('typescript').
ForkTsCheckerWebpackPlugin.ONE_CPU - always use one CPUForkTsCheckerWebpackPlugin.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)If you turn on webpacks watch mode the fork-ts-checker-notifier-webpack-plugin will take care of logging type errors, not webpack itself. That means if you set silent: true you won't see type errors in your console in watch mode.
You can either set silent: false to show the logging from fork-ts-checker-notifier-webpack-plugin or set async: false. Now webpack itself will log type errors again, but note that this can slow down your builds depending on the size of your project.
You may already be using the excellent webpack-notifier plugin to make build failures more obvious in the form of system notifications. There's an equivalent notifier plugin designed to work with the fork-ts-checker-webpack-plugin. It is the fork-ts-checker-notifier-webpack-plugin and can be found here. This notifier deliberately has a similar API as the webpack-notifier plugin to make migration easier.
At present there is an issue with the plugin regarding the triggering of type-checking when a change is made in a source file that will not emit js. If you have a file which contains only interfaces and / or types then changes to it will not trigger the type checker whilst in watch mode. Sorry about that.
We hope this will be resolved in future; the issue can be tracked here.
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-before-start | Async plugin that can be used for delaying fork-ts-checker-service-start | - |
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 |
new ForkTsCheckerWebpackPlugin({
tslint: true,
vue: true
})
.vue files, you need to ensure your script tag's language attribute is set
to ts or tsx (also make sure you include the .vue extension in all your import statements as shown below):<script lang="ts">
import Hello from '@/components/hello.vue'
// ...
</script>
ts-loader (in transpileOnly mode). Your Webpack config rules may look something like this:{
test: /\.ts$/,
loader: 'ts-loader',
include: [resolve('src'), resolve('test')],
options: {
appendTsSuffixTo: [/\.vue$/],
transpileOnly: true
}
},
{
test: /\.vue$/,
loader: 'vue-loader',
options: vueLoaderConfig
},
tslint.json and they will be applied to Vue files. For example, you could apply the Standard JS rules tslint-config-standard like this:{
"defaultSeverity": "error",
"extends": [
"tslint-config-standard"
]
}
tsconfig.json includes .vue files:// tsconfig.json
{
"include": [
"src/**/*.ts",
"src/**/*.vue"
],
"exclude": [
"node_modules"
]
}
// tsconfig.json
{
"compilerOptions": {
// ...
"baseUrl": ".",
"paths": {
"@/*": [
"src/*"
],
"~/*": [
"src/*"
]
}
}
}
// In a .ts or .vue file...
import Hello from '@/components/hello.vue'
MIT
v1.0.0-alpha.9
FAQs
Runs typescript type checker and linter on separate process.
The npm package fork-ts-checker-webpack-plugin receives a total of 7,979,059 weekly downloads. As such, fork-ts-checker-webpack-plugin popularity was classified as popular.
We found that fork-ts-checker-webpack-plugin demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.