Significant slowdown for import/no-unused-modules rule after upgrade from v2 to v3

[galkin]

I have medium size TypeScript project.
On v2 TIMING=1 npm run eslint shows

Rule	Time (ms)	Relative
import/no-unused-modules	5951.935	39.1%
import/namespace	3816.656	25.1%
deprecation/deprecation	2205.676	14.5%
@typescript-eslint/no-floating-promises	1131.970	7.4%
import/order	1024.044	6.7%
@typescript-eslint/no-unused-vars	244.425	1.6%
import/no-unresolved	130.393	0.9%
import/no-named-as-default-member	113.815	0.7%
import/default	87.840	0.6%
import/no-named-as-default	84.351	0.6%

On v3 TIMING=1 npm run eslint shows

Rule	Time (ms)	Relative
import/no-unused-modules	44214.254	73.7%
import/namespace	10107.349	16.8%
deprecation/deprecation	2321.754	3.9%
@typescript-eslint/no-floating-promises	1189.986	2.0%
import/order	1045.939	1.7%
@typescript-eslint/no-unused-vars	263.443	0.4%
import/no-unresolved	149.957	0.2%
import/no-named-as-default-member	101.459	0.2%
import/no-named-as-default	93.568	0.2%
import/default	87.550	0.1%

[JounQin]

cc @ljharb

Do you think anything would affect import/no-unused-modules in a resolver?

We're using enhanced-resolve in v3 to support imports/exports in package.json.

[JounQin]

Personally I don't think this should be related to this resolver, did you upgrade eslint-plugin-import at the same time? It could be a performance regression of rule import/no-unused-modules itself?

So a reproduction with only this resolver changed is required then.

@galkin

[ljharb]

@JounQin that's unfortunate; i can't speak to its performance though. When resolve is updated to handle exports, then the node resolver will get that functionality as well, and hopefully you'd be able to switch to that.

[JounQin]

When resolve is updated to handle exports, then the node resolver will get that functionality as well, and hopefully you'd be able to switch to that.

Of coure.

[JounQin]

close due to lack of reproduction, feel free to provide one, then I'll reopen it to dig.

[bordecal]

I am seeing a similar slowdown, with substantial increases in the timings for at least four import/* rules between recent eslint-import-resolver-typescript versions (with rule times in milliseconds as captured using TIMING=1 when running eslint):

Version	Total time	no-unused-modules	no-extraneous-dependencies	extensions	no-duplicates
2.7.1	1m 43s	10998	8251	3576	<2000
3.1.1	2m 39s	41996	27714	9541	4876
3.2.6	4m 8s	98067	58369	15159	13937

N.B.: The above timings were captured without changing the versions of any dependencies other than eslint-import-resolver-typescript.

[JounQin]

Please provide reproduction instead of just posting the timing table, it doesn't help anything.

[bordecal]

Unfortunately, I can't share my real project, and I don't really have time to create a repro from scratch, so I tried to find a large-ish existing project that is already using the import plugin. The Angular CLI seemed like a potentially good fit, and I was able to see a similar increase in linting time by adding then updating eslint-import-resolver-typescript. This was done over a series of commits that have been pushed to a new branch in a fork of the angular-cli repo:

1. c33d70c
   a. Prevents eslint caching (for benchmarking purposes)
   b. Adjusts eslint configuration to include rules for which timings have increased in my real code base.
   c. Captures baseline timings in linting/timings.txt.
2. 937e51d
   a. Adds eslint-import-resolver-typescript 2.7.1 as a dev dependency.
   b. Adjusts eslint configuration to use eslint-import-resolver-typescript as a resolver for the import plugin.
   c. Updates timings file with new timings.
3. 8cbe105
   a. Updates eslint-import-resolver-typescript from version 2.7.1 to version 3.1.1.
   b. Updates timings file with new timings.

Upgrading from v2.7.1 to v3.1.1 resulted in an increase in a 550% increase in overall linting time, with large increases in execution duration for the same rules mentioned in my earlier comment:

Version	Total time	no-unused-modules	no-extraneous-dependencies	extensions	no-duplicates
2.7.1	1m 14s	18394	2969	906	3070
3.1.1	6m 52s	161792	59664	11237	70562

Does this provide a sufficient repro? If not, what exactly might you be looking for?

[bordecal]

Not sure if this might help isolate the root cause, but something I saw in another issue made me wonder about the potential impact of resolver order. I checked the resulting configuration using --print-config, and it listed the typescript resolver before the node resolver:

  "settings": {
    "import/resolver": {
      "typescript": {},
      "node": {
        "extensions": [
          ".ts",
          ".tsx",
          ".js",
          ".jsx"
        ]
      }
    },
    //...

I tried adjusting the eslint configuration to list the node resolver before the typescript resolver. and this does seem to resolve the performance problem completely: bordecal/angular-cli@b36b624

[JounQin]

The significant change should be enhaced-resolve for supporting custom exports fields, in v1 it's not supported at all. If you have more genius solution, feel free to PR.

I tried adjusting the eslint configuration to list the node resolver before the typescript resolver.

The node resolver does not support exports at all, neither .d.ts/@types, so the comparison is unfair.

[JounQin]

Can you try `unsafeCache` provided by [`enhanced-resolve`](https://github.com/webpack/enhanced-resolve#resolver-options)?