Unusual slowness with yarn 2 PnP feature

Hi,

I realize that part of this issue is probably tied to the module resolution of yarn 2 Plug’n’Play being somewhat slower than the classic module resolution (with node_modules) and not directly to this plugin, but the difference between the two is so huge that it probably deserves to be pointed out.

Here is the (ridiculous) timing on a subset of my codebase with the yarn 2 PnP setup:

Rule                            |  Time (ms) | Relative
:-------------------------------|-----------:|--------:
import/no-cycle                 | 466543.870 |    76.3%
import/namespace                |  72755.307 |    11.9%
import/no-deprecated            |  69208.805 |    11.3%
indent                          |    302.711 |     0.0%
react/no-unknown-property       |    158.732 |     0.0%
react/destructuring-assignment  |    111.274 |     0.0%
import/no-unresolved            |     94.284 |     0.0%
no-unused-vars                  |     63.699 |     0.0%
react/prefer-stateless-function |     63.131 |     0.0%
react/no-deprecated             |     60.052 |     0.0%

10 minutes of eslint eating up 100% of my CPU.

For reference when ran on the full codebase (still relatively small) with a classic node_modules/ setup:

Rule                                | Time (ms) | Relative
:-----------------------------------|----------:|--------:
import/no-cycle                     |   683.181 |    16.1%
indent                              |   409.251 |     9.7%
import/namespace                    |   350.774 |     8.3%
react/no-unknown-property           |   302.858 |     7.1%
import/no-unresolved                |   191.842 |     4.5%
react/destructuring-assignment      |   123.256 |     2.9%
react/prefer-stateless-function     |    97.292 |     2.3%
react/no-deprecated                 |    86.106 |     2.0%
react/void-dom-elements-no-children |    71.407 |     1.7%
no-unused-vars                      |    57.248 |     1.4%

My best guess is that since with yarn 2 PnP there are no more node_modules/, instead the dependencies are kept in .yarn/cache/ as .zip files, resolving them takes longer and since eslint-plugin-import is probably trying to resolve a ton of modules to do his job it takes a long time.

That said, that’s the first thing for which that supposedly slower resolve (I don’t actually know if it’s true or not, that’s just a guess) is an issue for me. Webpack handles it fine for example.

So maybe, and again I’m guessing here, eslint-plugin-import could keep a “cache” of the modules it already resolved instead of re-resolving a module when it sees it again?

Let me know if you want more information.

[larowyn]

I figured out the problem, one of my own package had the main property of the package.json pointing to the built version so eslint was parsing that built version instead of the sources. Correcting that, fixes it.

[ljharb]

I’m not sure why that would make a difference 😕