Eslint-plugin-import: v2 is SLOW

Created on 7 Oct 2016  路  12Comments  路  Source: benmosher/eslint-plugin-import

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?

Most helpful comment

@indeyets good news, with the fixes in b35d489 your freefeed-server project lints in <10s, without the import/ignore setting. 馃槄 will publish ASAP!

All 12 comments

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

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.

@benmosher I added the following to my .eslintrc:

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

it doesn't help

@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.

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"]
  }
}

@indeyets:

"import/ignore:": [

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

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. 馃槃

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

Cool!

@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.

reopening because I want to fix in v3

@indeyets good news, with the fixes in b35d489 your freefeed-server project lints in <10s, without the import/ignore setting. 馃槄 will publish ASAP!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ljharb picture ljharb  路  29Comments

thewilkybarkid picture thewilkybarkid  路  36Comments

graingert picture graingert  路  22Comments

kirill-konshin picture kirill-konshin  路  22Comments

steve-taylor picture steve-taylor  路  24Comments