Bug: Failed to read tmpfile contents for ESLint

[brynary]

What happened?

ESLint is erroring, and then qlty is trying to read a non-existent tmpfile. The tmpfile was never written, because ESLint errored.

The root cause here is that for certain ESLint versions we are misinterpreting some exit codes as success that really mean failure.

What did you expect to happen?

Since ESLint errored

Can you reproduce the problem?

Only sometimes

CLI Version

Current

Relevant log output

No response

[marschattha]

I remember this came up before.

The issue was that for older versions of Eslint the exit code when there is an issue and when Eslint errors used to be the same, so we could not differentiate when it ran successfully with issues reported or crashed.

Taking a look of what we can do when this happens.

[brynary]

Thanks. Yes, I think it may be the difference between versions e.g. 5 vs 8.

Maybe we can use the same version-specific plugin definition trick we use for v8 vs v9 to solve for this

[marschattha]

No that won't work in this case, because ESLint 5 with exit code 1 could mean either it has found lint issues (tmpfile will be present) or crashed (tmpfile won't be present).

I think presence of the tmpfile is going to become a branch statement somehow.

[brynary]

Interesting. Does ESLint v5 allow any CLI arguments to customize the exit code behavior?

[marschattha]

Couldn't find any docs on older versions, but it seems this was an issue before v5, so until 4.x.

Here is the issue surrounding it and the PR which introduced a new exit code 2 for fatal crashes.

I could not find anything that would suggest that there is a flag/cli arg that could change this behaviour.