Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

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: aduth <[email protected]>
Co-authored-by: manzoorwanijk <[email protected]>
Co-authored-by: Mamaduka <[email protected]>

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

Size Change: 0 B

Total Size: 7.96 MB

_{compressed-size-action}

The ESLint errors are rather interesting and surprising:

Error: /home/runner/work/gutenberg/gutenberg/packages/scripts/config/jest-environment-puppeteer/index.js: line 35, col 2, Error - Unexpected console statement. (no-console)
Error: /home/runner/work/gutenberg/gutenberg/packages/scripts/config/jest-environment-puppeteer/index.js: line 72, col 5, Error - Unexpected console statement. (no-console)
Error: /home/runner/work/gutenberg/gutenberg/packages/scripts/config/jest-github-actions-reporter/index.js: line 31, col 4, Error - Unexpected console statement. (no-console)

The pattern '**/{bin,scripts,tools}/**' does match these files, but it's still failing. What's happening is that when inspecting those files, ESLint is walking up and stopping at the eslint.config.cjs file it discovers in packages/scripts/config/ and using that instead of the project-level configuration in tools/eslint/config.mjs.

I don't think files in this package should be ignoring the Gutenberg-wide configuration. In practice that would likely mean shuffling files around. Maybe renaming eslint.config.cjs to something like base.config.cjs. But this file was just introduced in #76654 and advertised in the CHANGELOG entry so that would likely be another breaking change.

Curious for your impressions here @manzoorwanijk . Personally I feel like we should probably have an exports entry in the scripts package.json if we want people to be using the file directly. Even the .cjs file extension alone feels pretty unstable and likely something we'd want to change at some point in the future.

In the interim, I might just go ahead and restore those eslint-disable comments so that the build will pass.

Flaky tests detected in 10e53e2.
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/25883753470
📝 Reported issues:

• [Flaky Test] should disable Save draft button during a multi-file gallery upload #77701 in /test/e2e/specs/editor/various/upload-save-lock.spec.js
• [Flaky Test] should insert media, convert to blocks, and undo in one step #77705 in /test/e2e/specs/editor/blocks/classic.spec.js

I don't think files in this package should be ignoring the Gutenberg-wide configuration. In practice that would likely mean shuffling files around. Maybe renaming eslint.config.cjs to something like base.config.cjs. But this file was just introduced in #76654 and advertised in the CHANGELOG entry so that would likely be another breaking change.

Curious for your impressions here @manzoorwanijk . Personally I feel like we should probably have an exports entry in the scripts package.json if we want people to be using the file directly. Even the .cjs file extension alone feels pretty unstable and likely something we'd want to change at some point in the future.

One idea I have is that we could use exports to maintain the current file-based API surface pointing to a file placement that doesn't cause the sort of auto-discovery conflicts I ran into, and soft-deprecate toward "optimal" subpath exports, e.g.

{
  "exports": {
    "./config/eslint.config.cjs": "./config/eslint/config.cjs",
    "./config/eslint": "./config/eslint/config.cjs",
    // ...
  }
}

Plus maybe a deprecation notice for anyone importing through ./config/eslint.config.cjs to nudge them to the new permanent subpath, allowing us to remove it as a breaking change at some point in the future.

Sorry, I missed that comment earlier. I has a similar situation when I migrated ESLint config to tools/eslint in #77215 and thus I renamed the file from ‎eslint.config.mjs‎ to ‎tools/eslint/config.mjs

I created a follow-up issue at #78346 so we can explore what a solution would look like.