Separate exit code for error

Tell us about your environment

• ESLint Version: Any
• Node Version: 6
• npm Version: None, I use Yarn latest.

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

Not relevant.

What did you do? Please include the actual source code causing the issue.

Running an eslint instance which should crash (config error, intern failing like a permission issue…)

What did you expect to happen?

Having a different exist code issue.

What actually happened? Please include the actual, raw output from ESLint.

The exit code issue is the same as a well running eslint with rule violation detection.

Currently, eslint give the same exit code when some lint rules are not respected and when the binary is failing (example: When the provided configuration file does not exists).

On a automated script, we can’t see the difference.

It would be great to have different exit codes:

• 1 For not respected lint rules.
• 2 When eslint is failing

Thanks.

[ilyavolodin]

I would be against doing that. Introducing an option now just to remove it in a few month doesn’t seem like a good idea. I understand @Soullivaneuh desire to have a working solution now, but it feels like it’s a lot more work for us to do that (introduce a new option, retire a new option, move the code around, etc.).

[nzakas]

Traditionally, we have decided against multiple exit codes because there hasn’t been a lot of evidence that multiple exit codes provide enough value to risk breaking existing integrations that might have logic looking only for exit code 1 (like if (exitCode != 1)). My opinion has generally been the same as Ilya’s in that if something the lint fails for any reason, then you need to look at it, so it only matters that the exit code isn’t zero.

As a reminder, we had an ill-fated experiment where we (actually me) changed the exit code to be the number of lint errors. We had to roll that back because it broke a lot of things, especially when the number of problems was > 254. That’s part of why we’ve been so reluctant to change exit codes since then.

That said, I can see an argument for making this change as the output for limiting problems vs. a crash is different, and I can see it being helpful for tools to be able to know how to bubble up the error details.

So I’m 👍 for keeping exit code 1 for linting errors and introducing exit code 2 for any other type of errors. That would be a breaking change and would have to go in on a major release. I wouldn’t want separate exit codes for every type of error condition as I think that’s overkill.