-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Update: include ruleId
in error logs of crash (fixes #15037)
#15053
Update: include ruleId
in error logs of crash (fixes #15037)
#15053
Conversation
|
Hi @AriPerkkio!, thanks for the Pull Request The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
8253b43
to
de4f783
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just one suggestion for a better comment.
de4f783
to
9328a38
Compare
Applied suggestion related to comment rephrasing. Thanks for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:
Fixes #15037.
What changes did you make? (Give an overview)
Added error handling around rule listener calls in
linter.js
. The error handler wrapper is added whensafe-emitter
listeners are created. This seemed like a good place for it since we haveruleId
easily available.When extending caught error in try-catch of
runRules
calls it is checked whetherruleId
is available. If it's found we include it in theerror.message
. This seems safe and low-risk.There were already few test cases available which nicely covered this case. I did not add any new test cases for this reason.
Example error log generated by this implementation is found from issue description.
Is there anything you'd like reviewers to focus on?
Currently the
ruleId
is wrapped with quotes, as inRule: "some-plugin/some-rule"
/Rule: "some-builtin-rule"
. I'm not sure whether quotes should be removed.