Performance: plugin adds 650-770ms to ESLint startup time

[victor-homyakov]

ESLint is frequently used in pre-commit hooks. Just adding plugin @typescript-eslint/eslint-plugin to the ESLint configuration makes linting and commiting noticeably slower even when there is nothing to lint.

Repro

1. Create clean new folder
2. Install npm i eslint typescript @typescript-eslint/eslint-plugin
3. Create script and execute it in Node.js:

const label = 'require plugin';
console.time(label);
const plugin = require('@typescript-eslint/eslint-plugin');
console.timeEnd(label);

Expected Result
The less the better

Actual Result
650 - 770 milliseconds on MacBook Pro with 2,7 GHz Intel Core i5. In other words, just adding this plugin slows startup of ESLint by 650-770ms.

Additional Info

Versions

package	version
@typescript-eslint/eslint-plugin	2.3.2
TypeScript	3.6.3
ESLint	6.5.1
node	8.6.0
npm	6.2.0

[bradzacher]

There is no way around this, unfortunately.
In order to provide type information to rules that consume it, we need to wear the cost of a typescript typecheck cycle across the codebase.

There are a few things we're looking into to reduce this pref hit a bit, but there will always be a non-zero cost to providing type information.

If you think that is unacceptable for your pre-commit hooks, then I would suggest changing your pre-commit hook to lint with a slimmed down set of rules that don't require type information.

[victor-homyakov]

In order to provide type information to rules that consume it

At least you could decrease startup time in the case when the rules are not triggered at all

[bradzacher]

That request makes no sense though.

In order to determine if a rule has triggered, we have to run the rule on the codebase. In order to run the rule we need to give it parsed files with type information. In order to give it parsed files with type information, we need to incur the runtime penalty.

[victor-homyakov]

For example, in a pre-commit hook, when a commit does not contain *.ts *.tsx files, there is no TypeScript to check.

[platinumazure]

ESLint does not currently provide a great way for plugins to see what files are going to be linted, before linting actually starts. If it did, then maybe typescript-eslint could change parser options based on that knowledge.

There are other plugins that could benefit from that sort of "pre-lint hook" as well. It's something we (ESLint) are thinking about. But we don't have anything concrete yet.

At this point, I don't think there's much typescript-eslint can do here, until core ESLint provides some of those extra hooks.

[bradzacher]

An additional point is that if you've configured eslint to use our parser on non ts files, then it will attempt to get type information for those files as well. It doesn't special case files. Via jsdoc, type inference, and your @types packages, typescript can actually provide very good type information for js files.

If you don't want your js/jsx files to be parsed with our parser because you don't want/need the type information rules on those files, it's on you to configure appropriately.