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

import/namespace in combination with @vercel/node is increasing the linting time by a factor of x80 #2527

Open
ChristianIvicevic opened this issue Aug 20, 2022 · 4 comments

Comments

@ChristianIvicevic
Copy link

ChristianIvicevic commented Aug 20, 2022

Repo for reproduction is here: https://github.com/ChristianIvicevic/import-namespace-issue-repro

I noticed that eslint takes ages linting the single file in this repo and profiling timings yields the following:

Rule                                      | Time (ms) | Relative
:-----------------------------------------|----------:|--------:
import/namespace                          |  8546.897 |    99.8%
@typescript-eslint/no-floating-promises   |     9.076 |     0.1%
@typescript-eslint/no-unused-vars         |     1.006 |     0.0%
@typescript-eslint/no-unsafe-argument     |     0.989 |     0.0%
@typescript-eslint/no-misused-promises    |     0.556 |     0.0%
@typescript-eslint/ban-types              |     0.318 |     0.0%
@typescript-eslint/no-empty-function      |     0.270 |     0.0%
@typescript-eslint/no-loss-of-precision   |     0.257 |     0.0%
@typescript-eslint/triple-slash-reference |     0.220 |     0.0%
@typescript-eslint/no-unsafe-call         |     0.163 |     0.0%

After trial-and-error I noticed that the offending line is this:

https://github.com/ChristianIvicevic/import-namespace-issue-repro/blob/9ec4d56d22280ad3d94671fb282262107dd47304/.eslintrc.js#L38-L40

Removing all JS extensions fixes the abysmal speed of import/namespace:

Rule                                       | Time (ms) | Relative
:------------------------------------------|----------:|--------:
import/namespace                           |    92.790 |    87.9%
@typescript-eslint/no-floating-promises    |     8.542 |     8.1%
@typescript-eslint/no-unsafe-argument      |     0.962 |     0.9%
@typescript-eslint/no-unused-vars          |     0.843 |     0.8%
@typescript-eslint/no-misused-promises     |     0.468 |     0.4%
@typescript-eslint/no-empty-function       |     0.249 |     0.2%
@typescript-eslint/ban-types               |     0.209 |     0.2%
@typescript-eslint/no-loss-of-precision    |     0.202 |     0.2%
@typescript-eslint/no-unsafe-member-access |     0.136 |     0.1%
@typescript-eslint/no-unsafe-call          |     0.127 |     0.1%

For the time being I have disabled import/namespace for my lambdas that import @vercel/node. In the rest of my project this is a non-issue, it's just in combination with that package that eslint is stuck doing... something.

@ljharb
Copy link
Member

ljharb commented Aug 23, 2022

The slow part is the ExportMap.get call, which has to build up a dependency graph of everything - including @vercel/node, which must take awhile to traverse.

If you enable multiple import rules that use the ExportMap, whichever is first will be "blamed" for being slow, and the rest will be fast. In other words, this doesn't have anything to do with namespace specifically, but something with the ExportMap combined with @vercel/node.

@ChristianIvicevic
Copy link
Author

@ljharb Is there anything either the plugin can do to better or that @vercel/node can improve?

@ljharb
Copy link
Member

ljharb commented Aug 24, 2022

Almost certainly yes on both counts - #2531 may help, if @vercel/node imports an inordinate number of type definitions from d.ts files, but beyond that, someone would have to do some pretty thorough debugging to figure out what was making it slow.

@n0099
Copy link

n0099 commented Dec 20, 2023

related: #2340

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants