Eslint-plugin-import: no-unresolved async

[AlexMost]

Hi, thanks for your plugin!
I tried to use no-unresolved rule on our project. We have a huge codebase and I found that this rule slows down the lint time significantly. I looked through the plugin code and found that resolve logic works synchronously, and as I am using node-resolver I think this thing blocks the main thread. Is there are any plans to make resolve logic async? I can try to make a PR with changes.

My eslint setting for the plugin:

{
"import/no-unresolved": 2,
"settings": {
    "import/resolver": {
      "node": {
        "paths": [
                 ...
        ],
        "extensions": [
          ".js",
          ".jsx",
          ".json"
        ]
      }
    }
  }

[ljharb]

JS is single-threaded; making it async wouldn’t make it complete any faster, it’d just allow other tasks to interleave with it.

[AlexMost]

@ljharb thanks for reminding) But the single thread is the main reason why you should avoid blocking (sync operations).

[ljharb]

That is only true when there are other operations you want to attend to, interleaved. In this case, there aren’t - and eslint’s nature is such that i suspect the rules would need to block anyways, even if thus part was async.

This rule should still ideally be made faster, but async isn’t likely to help much imo. However, using the worker_threads module when available might help a lot.

[AlexMost]

ok how about this?)

[AlexMost]

more detailed

[AlexMost]

In my case, I am running eslint with eslint-loader for webpack. I found that, just disabling this rule makes my build significantly faster.

[mk0x9]

Not sure if this issue is relevant, but this rule is really slow. And my project is only hundred files.

$ TIMING=1 node_modules/.bin/eslint "./src/**" --ext ".ts" -------SNIP------- Rule | Time (ms) | Relative :---------------------------------|----------:|--------: import/no-unresolved | 740.026 | 70.7% @typescript-eslint/no-unused-vars | 45.105 | 4.3% import/no-cycle | 22.265 | 2.1% import/no-useless-path-segments | 20.059 | 1.9% @typescript-eslint/camelcase | 16.276 | 1.6% import/order | 13.302 | 1.3% import/no-extraneous-dependencies | 12.172 | 1.2% import/named | 11.989 | 1.1% import/extensions | 10.941 | 1.0% compat/compat | 9.375 | 0.9%

[ljharb]

@mk0x9 it’s that the first rule is always slow because it builds up the import map; if you disable it, another one will be slow.

[benmosher]

@AlexMost / @mk0x9, you are right that it is a very slow rule, and I think async actually would help a _little_ since it's doing IO but unfortunately for this project (but appropriately for almost every other plugin), ESLint is architected for CPU-bound pure functions of ASTs.

This rule (and others within this plugin) are in many cases I/O bound functions that require external inputs (e.g. full imported dependency code!). I/O is just so, soooo much slower than anything CPU-bound.

I also work in a large project and am unable to use eslint-loader because it is very slow for these rules. This is the cost of using this plugin, unfortunately, and I'm not sure it can be avoided if you want the benefits.

That said, if I am totally wrong and there is a way to async this stuff for better performance (maybe something in the latest ESLint?) I welcome such a PR 👍🏼

Closing because nothing is planned for this at this time.

[mk0x9]

@benmosher thanks for the extensive reply!

But is it possible to store cache somewhere alongside with checksums and timestamps of the files so plugin will rebuild import map from the cache instead of re-reading the whole repo each time editor starts eslint to recheck file?

[benmosher]

It sure is! If you use eslint_d, the cache is preserved in memory between linting runs and it can drastically improve performance. Similarly, I think the VSCode ESLint extension runs in-process and the cache is retained there.

I have considered writing cache files to disk to make it faster but have not ever implemented that. Would be a neat project: extract an interface for the existing memory-only ModuleCache and implement a second version that can hit FS cache.