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:
Is this expected?
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!
Most helpful comment
@indeyets good news, with the fixes in b35d489 your
freefeed-serverproject lints in <10s, without theimport/ignoresetting. 馃槄 will publish ASAP!