Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Performance: plugin adds 650-770ms to ESLint startup time #1040
ESLint is frequently used in pre-commit hooks. Just adding plugin
const label = 'require plugin'; console.time(label); const plugin = require('@typescript-eslint/eslint-plugin'); console.timeEnd(label);
There is no way around this, unfortunately.
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.
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.
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.
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
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.