New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report fatal parsing errors differently than standard errors #13711
Comments
Thanks for the suggestion. I don’t think we can change the meaning of exit code 2 at this point, as that would be fairly unexpected to a lot of systems. Right now 2 effectively means ESLint crashed and changing that has consequences. Adding a 3 that is less severe than 2 also doesn’t seem like a good idea. An alternative approach could be to add a command line option so you could opt-in to the behavior you’re describing. I’m not opposed to something like that as I think reporting parsing errors in a different way can make sense in some situations. Just FYI: a proposal like this would need to go through our RFC process, and I’d wait for more feedback from the team before starting that. |
@nzakas , thank you for the feedback, I agree with your point of view. What about introducing option called Sample proposal for docs to better describe what I meant:
I'll be waiting for the feedback, thank you. |
That could work. We need to get some more feedback from the team before proceeding to the RFC phase. |
Does parsing errors come under internal error? if yes, I guess we can go with the exit code 2 itself (breaking change)? |
I think keeping a split between ESLint internal errors (exit code 2) and parser errors makes sense - ESLint is not responsible for what custom parser is doing. I did a quick & dirty implementation of the proposal (mainly as an exercise): master...tosmolka:max-fatal-errors . In there |
I agree with @nzakas that we shouldn't change the default behavior. Parsing error can be just an error in the code being linted (like a missing An option to change this behavior if a different exit code would be more suitable for some use cases makes sense to me. |
I think It has a similar name as Maybe we could add a boolean option instead of a threshold number? Also, 3 usually indicates a more severe error than 2, while this is at most equal to scenarios that produce exit code 2, so the same exit code 2 might make more sense than introducing a new exit code 3? |
@nzakas, @anikethsaha, @mdjermanovic, @mysticatea, any updates regarding the proposal? I think open questions need some attention from eslint team. We are ok with starting to return |
Like @nzakas I'm not opposed to an opt-in option to distinguish parsing errors from regular linting errors. I'm not thrilled with |
To add in this discussion I do agree that having this functionality would be better to have it as an argument/opt-in option as @nzakas mentioned. I do agree more with the suggestion by @mdjermanovic that having a bool options and simply fail in case of parser errors does make more sense from a user standpoint. For the names I would go for something like Are there any plans on picking up this functionality? |
@A-Katopodis while this isn't on the official roadmap (meaning that the core team won't be working on it), we are open to adding it if someone in the community would like to develop it. The next step would be to create an RFC with a concrete proposal that we can review. |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
@mdjermanovic i think you meant to reopen this. |
RFC has been merged and this is now ready to implement. |
@A-Katopodis just checking in to see if you intend to implement this? |
@nzakas I do plan starting the implementation next week. So you can expect it in 1-2 weeks time. |
Great, thanks! |
* Docs: Updated docs for exit-on-fatal-error * New: Added exit-on-fatal-error feature * Addressed PR feedback * Made description consistent * Updated dev docs for nodejs-api * Updated cmd docs * Added test case for 1 exit code * Fixed typos Co-authored-by: A-Katopodis <ankatopo@microsoft.com>
eslint v7.9.0
We have eslint integrated in our CI/CD pipelines and we would like to distinguish between cases when linting was successful and when linting failed due to fatal errors during parsing. Such errors are often caused by misconfigured parser or by trying to lint files with syntax errors.
Sample error:
We see such cases as unsuccessful linting and would like to propose exiting with exit code
2
. This seems in line with what can be read in the Exit codes docs:If eslint starts returning
2
we could fail early in the pipeline without parsing the result files (which we do only in later stages) and let the user know that linting was actually not successful and configs need to be changed (e.g. update parser options or ignore invalid files).Alternatively, we could consider introducing new exit code
3
that would cover just this case.Can you please review the proposal and let us know? We might have capacity for contribution but we would like to agree on the approach first. Thanks.
The text was updated successfully, but these errors were encountered: