Eslint-plugin-import: Memory issues with import/order autofixer in 2.11.0

Created on 19 Apr 2018 · 11Comments · Source: benmosher/eslint-plugin-import

After upgrading to 2.11.0 my linting process started to fail due to running out of memory. The reason seem to be the autofixer for the import/order rule, because either

running linter without --fix option or
disabling the import/order rules in .eslintrc

makes it working fine again. This is what I see in the console:

<--- Last few GCs --->

[23224:0000012CB4B8B680]   137777 ms: Mark-sweep 1400.1 (1486.3) -> 1400.1 (1486.3) MB, 1995.8 / 0.0 ms
 allocation failure GC in old space requested
[23224:0000012CB4B8B680]   139784 ms: Mark-sweep 1400.1 (1486.3) -> 1400.1 (1455.3) MB, 2006.7 / 0.0 ms
 last resort
[23224:0000012CB4B8B680]   141845 ms: Mark-sweep 1400.1 (1455.3) -> 1400.1 (1455.3) MB, 2059.5 / 0.0 ms
 last resort


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 000000DD8DD1BBE9 <JS Object>
    1: walk(aka walk) [(redacted)\node_modules\typescript-eslint-parser\lib
\node-utils.js:~716] [pc=0000014687C787FF](this=000000DD8DD02241 <undefined>,node=00000374E5FA2321 <a To
kenObject with map 0000033396E2CAF9>)
    2: arguments adaptor frame: 3->1
    3: InnerArrayForEach(aka InnerArrayForEach) [native array.js:~776] [pc=000001468819EC38](this=000000
DD8DD022...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

I was asked to create this issue with a link back to the PR that introduced autofixer for this rule, so here it is:
https://github.com/benmosher/eslint-plugin-import/pull/908

Just in case, here's my config for the import/order rule:

    "import/order": [
      "error",
      {
        "groups": [
          [
            "builtin",
            "external"
          ],
          [
            "internal",
            "index",
            "sibling",
            "parent"
          ]
        ],
        "newlines-between": "ignore"
      }
    ]

bug help wanted imporexport ordering

Source

JakubJagoda

All 11 comments

We used autofix order on a large codebase (1000s of files) where it had a failure on every file. First run through was very slow as you would expect, then it was fine after fixing. No memory issues.

How many errors do you have if not fixing?
Can you narrow it down to one file?
If you increase the memory limit for the node process does it eventually complete?

lukeapage on 19 Apr 2018

I have assumptions what may cause memory overconsumption, but i want to reproduce the problem.

@JakubJagoda in addition, please provide your node.js version.

tihonove on 20 Apr 2018

@lukeapage I have 0 errors, I discovered the problem by accident after adding a new file. I can't really narrow it down to a single file, because it's not a matter of a single file - whenever there's an incorrect import order in any of the files, the problem happens. When I, according to your advice, had increased the memory limit (using package increase-memory-limit) it ran for like 20 minutes (way longer than previously, when the memory error happened), but didn't complete either, this time with a JS error:

Invalid string length
RangeError: Invalid string length
    at attemptFix ((redacted)\node_modules\eslint\lib\util\source-code-fixer.js:104:22)
    at Function.SourceCodeFixer.applyFixes ((redacted)\node_modules\eslint\lib\util\source-code-fixer.js:123:17)
    at Linter.verifyAndFix ((redacted)\node_modules\eslint\lib\linter.js:1141:43)
    at processText ((redacted)\node_modules\eslint\lib\cli-engine.js:180:32)
    at processFile ((redacted)\node_modules\eslint\lib\cli-engine.js:224:18)
    at fileList.map.fileInfo ((redacted)\node_modules\eslint\lib\cli-engine.js:550:20)
    at Array.map (native)
    at CLIEngine.executeOnFiles ((redacted)\node_modules\eslint\lib\cli-engine.js:519:34)
    at Object.execute ((redacted)\node_modules\eslint\lib\cli.js:189:111)
    at Object.<anonymous> ((redacted)\node_modules\eslint\bin\eslint.js:74:28)

Do you also use typescript-eslint-parser in your setup?

@tihonove I am using Node 8.2.1 on x64 Windows. I wish I could give the project that causes the problem, but unfortunately I can't do that due to legal reasons.

JakubJagoda on 20 Apr 2018

It seems like it might be some infinite loop to do with typescript-eslint-parser ?

Can you reproduce with a new file with just 2 import statements? If so you could post the contents of that with changed file paths.. if that doesn’t reproduce, what does?

lukeapage on 21 Apr 2018

Also running across this. also using typescript-eslint-parser with a large codebase