Flaky tests detected in 8a2bccc.
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/24663295540
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js

Size Change: 0 B

Total Size: 7.75 MB

_{compressed-size-action}

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: mirka <0mirka00@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>

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

I'm not really sure I follow the need for the wrapper script. From what I can tell the base behavior does a good enough job of explaining what needs to be done, and exiting with a non-zero status code? Is it so we can point to the custom convenience script and include an instruction to commit?

Is it so we can point to the custom convenience script and include an instruction to commit?

Yes. Especially in the lint-staged flow, I found it quite unclear which command I'm supposed to re-run with the flag. I feel like we should try to be as clear as possible here, given the feature is new to everybody. What do you think?

By the way I also considered pruning automatically for the absolute minimum friction, but that also seemed confusing since the feature is still unfamiliar.

In #77215, we are consolidating ESLint config into tools/eslint/. Should we ship that first and then update this with the paths accordingly? We can then also move eslint-suppressions.json to that sub-directory.

@manzoorwanijk Thanks for flagging. Agreed that eslint-suppressions.json belongs in tools/eslint/ alongside the rest of the config once #77215 lands.

I would prefer merging this one ASAP because it's ready to go, and we can cut down on later migration work the earlier we can start enforcing these ratcheted lints.

From looking at your PR, it looks like the move itself is small (file move, one constant in bin/lint-js.js, possibly a --suppressions-location flag), so it seems simple enough as a focused follow-up. Happy to follow up on that after it's merged.

Something worth noting that I noticed in testing: --prune-suppressions writes a new eslint-suppressions.json with two spaces, not tabs. This feels really prone to thrashing back and forth depending if someone applies Prettier to the file (as I expect you have done in this initial commit).

Added a formatting step in the wrapper script itself 👍

I'm still a little hesitant on the wrapper script. One future maintenance headache could be if ESLint changes the messaging in a future version that our pattern matching won't match anymore.

Altered the strategy so we don't try to do an exact match and suppress the original error message. Instead, only do a less fragile match on the string "--prune-suppressions" to detect the stale suppressions error and append our own message. Hoping this is a better compromise: