CI: Suppress lint:js warnings on static checks

[manzoorwanijk]

What?

Add --quiet to the Lint JavaScript step of the static checks workflow so lint:js reports only errors on CI.

Why?

actions/setup-node registers the eslint-compact problem matcher, so every ESLint warning is emitted as a ##[warning] line. Hundreds of react-hooks/exhaustive-deps warnings on pre-existing files bury the actual error in the log. These warnings are not useful as PR annotations either, since GitHub only annotates lines in the diff and caps annotations at 10 per step.

How?

--quiet makes ESLint drop warnings before output, so only errors are reported and a real error stands out. Error annotations on the diff are unaffected, and local npm run lint:js still shows warnings.

This PR includes a temporary commit introducing a lint error to demonstrate the result. See the resulting run: the error is reported cleanly without warning noise. That commit will be removed before merge.

Testing Instructions

1. Check the Static Analysis → Lint JavaScript step logs and confirm no react-hooks/exhaustive-deps warning lines appear.
2. Confirm genuine lint errors are still reported and still fail the job.
3. Run npm run lint:js locally and confirm warnings are still shown (the change is CI-only).

Use of AI Tools

I used Claude Code to investigate the problem-matcher behavior and draft this change. I reviewed and take responsibility for the result.

[github-actions]

Size Change: 0 B

Total Size: 8.44 MB

_{compressed-size-action}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

Makes sense to me, even with the search, it was still hard to find the right info.

[github-actions]

Flaky tests detected in b1f586e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27189782680
📝 Reported issues:

• [Flaky Test] shows post-locked modal when document size limit is exceeded #78753 in /test/e2e/specs/editor/collaboration/http-only/collaboration-document-size-lock.spec.ts

[aduth]

Separately, this might be good motivation to revisit those warnings, either enforcing them as errors or disabling them altogether. ESLint warnings provide almost no value to us, since people just ignore them anyways.

[manzoorwanijk]

Separately, this might be good motivation to revisit those warnings, either enforcing them as errors or disabling them altogether. ESLint warnings provide almost no value to us, since people just ignore them anyways.

I agree. Warnings don't help.

[Mamaduka]

ESLint warnings provide almost no value to us, since people just ignore them anyways.

They're still useful when folks are working on new components, and we should try to fix as many as we can.

Warnings can be a real problem if/when the project enables React Compiler.

[aduth]

I think if we care about those rules, we should mark it as an error, and use the suppressions feature to suppress existing issues.

[Mamaduka]

I think if we care about those rules, we should mark them as an error, and use the suppressions feature to suppress existing issues.

I don't think that would result in them resolving faster; we're using suppressions for legacy components, and I don't see better results there.

Another problem is that some effect warnings can't be clearly resolved without significant refactoring, or there's no clear alternative to "only run on mount". I think we should be able to clean up more of those once React 19 and useEffectEvent are available.

[aduth]

I don't think that would result in them resolving faster; we're using suppressions for legacy components, and I don't see better results there.

Several of the rules we currently have configured as warnings are increasing in count over time, so even if we did nothing with suppressions they're still resolving at a faster rate. 😂