Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
victor-homyakov opened this issue Oct 3, 2019 · 6 comments
Closed

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

victor-homyakov opened this issue Oct 3, 2019 · 6 comments

Comments

@victor-homyakov
Copy link

@victor-homyakov victor-homyakov commented Oct 3, 2019

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

This comment has been minimized.

Copy link
Member

@bradzacher bradzacher commented Oct 4, 2019

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.

@bradzacher bradzacher closed this Oct 4, 2019
@victor-homyakov

This comment has been minimized.

Copy link
Author

@victor-homyakov victor-homyakov commented Oct 4, 2019

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

This comment has been minimized.

Copy link
Member

@bradzacher bradzacher commented Oct 4, 2019

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

This comment has been minimized.

Copy link
Author

@victor-homyakov victor-homyakov commented Oct 4, 2019

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

@platinumazure

This comment has been minimized.

Copy link
Contributor

@platinumazure platinumazure commented Oct 4, 2019

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

This comment has been minimized.

Copy link
Member

@bradzacher bradzacher commented Oct 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.