eslint: Option to exit with success even if there are errors
Hi, we are using the eslint CLI together with npm for running eslint from the command line.
So far so good, apart that we’re also using parallelshell to run commands in parallel. The problem is, parallelshell kills all the running processes if one of them returns an exit status that’s not 0.
We managed to work around this by exiting manually:
eslint source ; exit 0
But since it’s quite ugly, is it possible to add an option to exit with 0 even on errors (like if they were just warnings)?
Thanks!
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 18
- Comments: 37 (28 by maintainers)
Commits related to this issue
- New: Add CLI option for exiting 0 (fixes #2949) Normally, if checks produce errors, ESLint exits with a status code of 1. With this option, it will always exit 0, even if there are errors. However, i... — committed to adamkasztenny/eslint by adamkasztenny 8 years ago
- New: Add CLI option for exiting 0 (fixes #2949) Normally, if checks produce errors, ESLint exits with a status code of 1. With this option, it will always exit 0, even if there are errors. However, i... — committed to adamkasztenny/eslint by adamkasztenny 8 years ago
I’m sorry, we decided not to pursue this any further. As I mentioned in my last comment, we recommend wrapping ESLint in something else if you want more control over exit codes.
tslint has:
I’m pretty sure tslint also lints JavaScript now…
Can this be reopened, strictly in terms of exiting with a different (non-zero) status code for “successful lint with errors” vs “ESLint threw an exception”? It doesn’t result in any magical success exit code when there were lint errors but it does help consumers who have to rely on the CLI distinguish between those cases.
@platinumazure that’s only tangentially related to this issue, and we can’t change that behavior anyway. We actually tried changing exit codes at one point and it caused massive problems for CI systems, so I don’t think it’s worthwhile to pursue.
How about a compromise? If
--output-fileattribute is passed on CLI, exit code should be 0 no matter the result of the linting.@nzakas - this is also a problem for us. We are using Phabricator which thinks the process had trouble running when it exits with an error code. Now on why we cannot make everything a warning is because we actually use the distinction between errors and “suggestions” where an “error” is a blocker (before submitting a patch) a “warning” is more of an advice but not enforced.
Our current workaround is using a “proxy” file which does
require('eslint/lib/cli').execute(process.argv);to both exit with an error code if something really breaks and silence the “lint error” case. That said I seelib/cliis also going away making this a bit harder.Does that make sense?