Skip to content

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

Merged
merged 30 commits into from
Jul 25, 2025
Merged

fix: Refactor reporting into FileReport #19877

merged 30 commits into from
Jul 25, 2025

Conversation

nzakas
Copy link
Member

@nzakas nzakas commented Jun 19, 2025

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 the createReportTranslator() 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 errors
  • addWarning/addWarnings - add one or more warnings
  • addFatal/addFatals - add one or more fatal warnings
  • addRuleMessage - add a message from a rule

It 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.

@nzakas nzakas requested a review from a team as a code owner June 19, 2025 19:10
@github-project-automation github-project-automation bot moved this to Needs Triage in Triage Jun 19, 2025
@eslint-github-bot eslint-github-bot bot added the chore This change is not user-facing label Jun 19, 2025
Copy link

netlify bot commented Jun 19, 2025

Deploy Preview for docs-eslint ready!

Name Link
🔨 Latest commit 15aef0a
🔍 Latest deploy log https://app.netlify.com/projects/docs-eslint/deploys/68839101bf8f6f0008a073b3
😎 Deploy Preview https://deploy-preview-19877--docs-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@github-actions github-actions bot added the core Relates to ESLint's core APIs and features label Jun 19, 2025
@nzakas nzakas requested a review from Copilot June 19, 2025 19:10
Copy link
Contributor

@Copilot Copilot AI left a 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) {

@nzakas nzakas moved this from Needs Triage to Implementing in Triage Jun 20, 2025
nzakas and others added 3 commits June 20, 2025 16:44
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
nzakas and others added 7 commits June 27, 2025 11:38
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>
nzakas and others added 8 commits July 1, 2025 16:28
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>
@nzakas
Copy link
Member Author

nzakas commented Jul 2, 2025

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.

mdjermanovic
mdjermanovic previously approved these changes Jul 3, 2025
Copy link
Member

@mdjermanovic mdjermanovic left a 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.

@mdjermanovic
Copy link
Member

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.

Is there anything particular in the API you think could be improved?

It 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.

Named methods look good to me. There's currently only one place where the code needs to have a conditional to call either addError or addWarning due to not knowing the severity in advance. If more such cases occur, we could consider adding another, generic method addMessage(severity, descriptor).

@nzakas
Copy link
Member Author

nzakas commented Jul 3, 2025

I feel like addError() and addErrors() is a bit clunky, maybe the methods should be merged into one?

Those methods and addRuleMessage() seem bit mismatched to me -- the different signatures, addRuleMessage() returns the message while the others don't.

I just feel like there could be a cleaner version of this API.

It also could just not matter at this point. 😄

@mdjermanovic
Copy link
Member

I feel like addError() and addErrors() is a bit clunky, maybe the methods should be merged into one?

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:

eslint/lib/linter/linter.js

Lines 469 to 472 in 8a46c15

report.addError({
message,
loc,
});

report.addErrors(directivesProblems);

Those methods and addRuleMessage() seem bit mismatched to me -- the different signatures, addRuleMessage() returns the message while the others don't.

I just feel like there could be a cleaner version of this API.

It also could just not matter at this point. 😄

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.

@lumirlumir lumirlumir added the accepted There is consensus among the team that this change meets the criteria for inclusion label Jul 7, 2025
@nzakas
Copy link
Member Author

nzakas commented Jul 9, 2025

Decided to just clean things up a bit:

  • Eliminated addWarnings, addErrors, and addFatals. It's easy enough to use forEach when necessary to accomplish the same thing
  • Updated addWarning, addError, and addFatal to return the newly-created LintMessage to match addRuleMessage()

I think this makes the API feels more cohesive.

@nzakas
Copy link
Member Author

nzakas commented Jul 11, 2025

@fasttime not critical to get this into the release but would appreciate a review.

mdjermanovic
mdjermanovic previously approved these changes Jul 12, 2025
Copy link
Member

@mdjermanovic mdjermanovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

fasttime
fasttime previously approved these changes Jul 14, 2025
Copy link
Member

@fasttime fasttime left a 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.

* @fileoverview Tests for createReportTranslator
* @author Teddy Katz
* @fileoverview Tests for FileReport class
* @author ESLint
Copy link
Member

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.

Copy link
Member Author

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.

Comment on lines -13384 to +13391
"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').",
);

Copy link
Member

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.

Copy link
Member Author

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.

@nzakas nzakas changed the title refactor: Reporting into FileReport fix: Refactor reporting into FileReport Jul 25, 2025
@eslint-github-bot eslint-github-bot bot added the bug ESLint is working incorrectly label Jul 25, 2025
@nzakas nzakas dismissed stale reviews from fasttime and mdjermanovic via 15aef0a July 25, 2025 14:13
@nzakas nzakas merged commit bbf23fa into main Jul 25, 2025
30 checks passed
@nzakas nzakas deleted the file-report branch July 25, 2025 14:21
@github-project-automation github-project-automation bot moved this from Implementing to Complete in Triage Jul 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion bug ESLint is working incorrectly chore This change is not user-facing core Relates to ESLint's core APIs and features
Projects
Status: Complete
Development

Successfully merging this pull request may close these issues.

4 participants