fork-ts-checker-webpack-plugin has, since its inception, performed two classes of checking:
- Compilation errors which the TypeScript compiler surfaces up
- Linting issues which TSLint reports
You may have caught the announcement that TSLint is being deprecated and ESLint is the future of linting in the TypeScript world. This plainly has a bearing on linting in
I've been beavering away at adding support for ESLint to the fork-ts-checker-webpack-plugin. I'm happy to say, the plugin now supports ESLint. Do you want to get your arms all around ESLint with
fork-ts-checker-webpack-plugin? Read on!
Well, first of all you need the latest and greatest
fork-ts-checker-webpack-plugin. Support for ESLint shipped with v1.4.0.
You need to change the options you supply to the plugin in your
webpack.config.js to look something like this:
You'll also need the various ESLint related packages to your
@typescript-eslint/parser: The parser that will allow ESLint to lint TypeScript code
@typescript-eslint/eslint-plugin: A plugin that contains ESLint rules that are TypeScript specific
If you want, you can pass options to ESLint using the
eslintOptions option as well. These will be passed through to the underlying ESLint CLI Engine when it is instantiated. Docs on the supported options are documented here.
Now you're ready to use ESLint, you just need to give it some configuration. Typically, an
.eslintrc.js is what you want here.
If you're a React person (and I am!) then you'll also need:
yarn add eslint-plugin-react. Then enrich your
eslintrc.js a little:
You can add Prettier into the mix too. You can see how it is used in the above code sample. But given the impact that has on performance I wouldn't recommend it; hence it's commented out. There's a good piece by Rob Cooper's for more details on setting up Prettier and VS Code with TypeScript and ESLint.
It's worth noting that support for TypeScript in ESLint is still brand new. As such, the rule of "Make it Work, Make it Right, Make it Fast" applies.... ESLint with TypeScript still has some performance issues which should be ironed out in the fullness of time. You can track them here.
This is important to bear in mind as, when I converted a large codebase over to using ESLint, I discovered that initial performance of linting was terribly slow. Something that's worth doing right now is identifying which rules are costing you most timewise and tweaking based on whether you think they're earning their keep.
TIMING environment variable can be used to provide a report on the relative cost performance wise of running each rule. A nice way to plug this into your workflow is to add the
cross-env package to your project:
yarn add cross-env -D and then add 2 scripts to your
lint- just runs the linter standalone
lint-rule-timings- does the same but with the
TIMINGenvironment variable set to 1 so a report will be generated.
I'd advise, making use of
lint-rule-timings to identify which rules are costing you performance and then turning
off rules as you need to. Remember, different rules have different value.