v2 is SLOW

[indeyets]

Upgrading eslint-plugin-import led to significant change in speed of eslint scan on several codebases I support.

For example, https://github.com/FreeFeed/freefeed-server:

• 1.x: 16 seconds
• 2.x: ~110 seconds

Is this expected?

[masylum]

Same here. I had to disable it because of the performance regression. Is there a way we can help?

[benmosher]

Interesting. Could be that the fail-fast regex for unambiguous module detection is getting a lot of false positives.

You could try using the import/ignore setting to ignore node_modules; if it helps considerably, I suspect this is the issue.

[indeyets]

@benmosher I added the following to my .eslintrc:

  "settings": {
    "import/ignore:": [
      "node_modules"
    ]
  },

it doesn't help

[jfmengels]

@indeyets Hmm, could you try to deactivate rules to find out which one is causing the lag? @benmosher seems to think it's the unambiguous rule, but it would be helpful to know for sure.

[masylum]

My configuration is this one if that can be helpful:

{
  "parser": "babel-eslint",
  "plugins": [
    "import",
    "react",
    "flowtype"
  ],
  "extends": [
    "plugin:import/errors",
    "plugin:import/warnings",
    "plugin:react/recommended",
    "plugin:flowtype/recommended",
    "standard",
    "standard-jsx",
    "standard-react"
  ],
  "rules": {
    "object-curly-spacing": ["warn", "always"],
    "flowtype/no-weak-types": [0, {
      "any": false,
      "Object": false,
      "Function": false
    }]
  },
  "settings": {
    "import/resolver": {
      "webpack": {
        "config": "webpack.config.js"
      }
    },
    "import/extensions": [".js", ".jsx"]
  }
}

[benmosher]

@indeyets:

"import/ignore:": [

Is that extra colon inside the quotes actually in your config?

[benmosher]

Btw @jfmengels + all: I'm not saying it's the unambiguous rule, I'm saying it's the new auto-ignore that parses dependencies to see if they have exports or imports, and ignores them if they don't.

Historically, most of the time is dependency parse time. There is a regex that is a lot faster than a full JS parse that should prevent parsing most non-ES-module deps. I'm thinking some part of that must not be working for @indeyets, thus my suspicion that explicitly ignoring node_modules would help a lot.

Probably just need to add some timing and debug logging and do some real forensics. 😅 I didn't notice a bug slowdown on my work projects with tons of CJS deps, so maybe those that have commented here have something going on that I don't yet understand. But if it was fast before, it should be able to be made fast again. 😄

[indeyets]

@benmosher you're right. the colon was an issue. I fixed the setting and scan-time is reasonable again 👍

[jfmengels]

Cool!

[benmosher]

@indeyets sweet! it does mean you're losing any linting of node_modules that have jsnext:main configured, though.

at some point I'd like to profile the linked project without ignoring node_modules and try to identify the issue; it still shouldn't be much different than v1.

[benmosher]

reopening because I want to fix in v3