-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
fix: Refactor reporting into FileReport #19877
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
Conversation
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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.
Pull Request Overview
This pull request refactors how lint errors and warnings are tracked by introducing a new FileReport class. It removes the creation of a per-rule report translator, consolidating message reporting, and updates tests accordingly.
- Introduces FileReport to handle error, warning, and fatal messages.
- Updates linter.js to use FileReport methods instead of pushing to arrays.
- Adjusts tests to reflect changed message order and severity mappings.
Reviewed Changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.
File | Description |
---|---|
tests/lib/linter/linter.js | Updates test expectations and accidentally left a focused test. |
lib/linter/linter.js | Integrates FileReport and refactors message reporting logic. |
Comments suppressed due to low confidence (2)
tests/lib/linter/linter.js:8953
- Remove 'describe.only' to ensure all tests run in the suite.
describe.only("Linter with FlatConfigArray", () => {
lib/linter/linter.js:411
- Verify that mapping numeric severity 1 to a warning and 2 to an error is intentional and consistent with ESLint's severity semantics throughout the codebase.
if (numericSeverity === 1) {
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
I'd also like some feedback on the API itself. I'm not satisfied with it at present, but I'm also not sure how I'd change it. |
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 if we want to keep this API.
Is there anything particular in the API you think could be improved?
Named methods look good to me. There's currently only one place where the code needs to have a conditional to call either |
I feel like Those methods and I just feel like there could be a cleaner version of this API. It also could just not matter at this point. 😄 |
Maybe, but two methods, one accepting a descriptor object, the other accepting an array of descriptor objects, as they are implemented now, seem a good fit for the usage we have: Lines 469 to 472 in 8a46c15
Line 671 in 8a46c15
I think it's fine as-is, at least for the start. I'd be in favor of merging this now since it's a fairly big diff so it could run into merge conflicts with other PRs, and we could revisit details at some later point. |
Decided to just clean things up a bit:
I think this makes the API feels more cohesive. |
@fasttime not critical to get this into the release but would appreciate a 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!
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 generally, just two questions.
tests/lib/linter/file-report.js
Outdated
* @fileoverview Tests for createReportTranslator | ||
* @author Teddy Katz | ||
* @fileoverview Tests for FileReport class | ||
* @author ESLint |
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.
Not sure if this was intentional or AI-generated.
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.
Haha yes, AI generated. I'll fix it.
"test/my-rule", | ||
null, | ||
); | ||
assert.strictEqual(messages[0].severity, 1); | ||
assert.strictEqual(messages[0].severity, 2); | ||
assert.strictEqual( | ||
messages[0].message, | ||
expectedRuleMessage, | ||
"Unused inline config ('test/my-rule' is already configured to 'warn').", | ||
); | ||
|
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.
I'm wondering if this change should be tagged as fix:
instead of refactor:
since it changes the order of messages in a lint report.
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.
I'll mark the PR as a fix.
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 autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
Refactor
What changes did you make? (Give an overview)
I moved the logic for tracking lint errors/warnings into a new class called
FileReport
. This replaces thecreateReportTranslator()
function, reducing the need to create a new report translator for each rule.refs #18787
Is there anything you'd like reviewers to focus on?
I'm unsure of the method names of
FileReport
. I decided to go with:addError
/addErrors
- add one or more errorsaddWarning
/addWarnings
- add one or more warningsaddFatal
/addFatals
- add one or more fatal warningsaddRuleMessage
- add a message from a ruleIt seemed like having named methods was less error-prone than requiring severity to always be passed or making it optional and defaulting to error. I'm not sure if we should combine the methods so one method can add one or more messages (so just
addError
but use rest arguments?). Any thoughts on these methods would be appreciated.