Avoid copying block-library CSS files twice - Option 1

[desrosj]

This removes duplicate block library-related CSS files in favor of the same location as WP 6.9: wp-includes/blocks.

Trac ticket: Core-64933

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet 4.6
Used for: Creating the initial PR based on a description of the problem.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

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

Core Committers: Use this line as a base for the props when committing in SVN:

Props desrosj, youknowriad.

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

[youknowriad]

How are we copying these styles from Gutenberg to Core?

[youknowriad]

The intent was not to move them to a new location with the build change, but we still need a way to copy them from the built Gutenberg. where is that being done now?

[youknowriad]

I see that some of what this script was meant to do has now moved to the Gruntfile. I'd love to understand more why this was done. I'd rather we move away from Grunt iteratively, and would prefer a single "copy" script for all the files that we move from Gutenberg build to a specific place in Core. I think that's clearer over random and unclear Grunt plugins.

[desrosj]

The intent was not to move them to a new location with the build change, but we still need a way to copy them from the built Gutenberg. where is that being done now?

Thanks for confirming! I went ahead and committed #11338 in r62103 to resolve this and confirmed that the build server reflected the desired outcome.

I see that some of what this script was meant to do has now moved to the Gruntfile. I'd love to understand more why this was done. I'd rather we move away from Grunt iteratively, and would prefer a single "copy" script for all the files that we move from Gutenberg build to a specific place in Core. I think that's clearer over random and unclear Grunt plugins.

Unfortunately, the original changes introduced more questions than were answered and created many more problems than were solved. Apologies that the refinements made since r61438 run counter to your personal preference. It was not at all clear that the desired outcome is to move away from Grunt entirely given that the original r61438 changeset introduced 5 new tasks and moved the handling of the wp-includes/js/dist/vendor files into Grunt. r61438 also removed nearly all of the Webpack-related code. Does that mean your goal is also to move away from Webpack entirely?

I'll admit, despite having spent over a month working on refining the build script (it took me over a week just to understand all of the moving parts after the changes made before I was confident enough to open pull requests to suggest improvements), I'm still very unclear about what the various motivations behind that changeset actually are and which parts of that commit address each one. Any time a major change to the underlying tooling is made, there must be clearly stated goals, a plan or roadmap when multiple stages are needed, reasonably broad discussions to ensure as many factors are accounted for as possible, and a level of confidence that there's a consensus that the new tool or approach is worth the tradeoffs. While the PR was lengthy and the ticket has had lots of discussion, I still have not seen this clearly addressed.

As for the rationale behind behind moving things out of custom scripts into Grunt, the overall goals guiding the decisions made since r61438 are:

• Avoid having multiple tools performing identical actions for different areas of the code base: copying files and directories, removing occurrences of sourceMappingURL= in JavaScript files, adding comments/file headers to files compiled in the build process, etc.
• Avoiding needless complexity: many wheels were reinvented through custom code without strong and/or compelling reasoning
• Ensure that the results of the build script are reproducible regardless of the date/time, local file locations/paths, or platform the script is run on.
• Building/copying/transforming only the intended files to the intended locations: many files were being included in the built package unintentionally, even after many refinements contributing to a package size for 7.0 that was more than double that of 6.9.

Grunt is not perfect by any means. But despite being considered a legacy tool, it still meets the overwhelming majority of the needs for this repository. There have been several discussions in the past to replace Grunt entirely, but those have all targeted Webpack as the replacement (see Core-49423 and Core-43731) and stalled for various reasons. I think this demonstrates that the broader contributing community agrees with you, but a solution that is worth the tradeoffs has not yet risen to the top.

I'm going to close the PR out since it has been resolved. But I'm more than happy to continue discussing, whether here or somewhere more visible such as #core-build-test-tools or #core.

[youknowriad]

Thanks for explaining.

It's not about Grunt being a legacy tool or not, it's more about clarity of flows.

1- Checkout Gutenberg
2- Build Gutenberg
3- Copy output from Gutenberg to the right places since it's already built.

Grunt is organized in random chunks without clear logic. With the single copy script the purpose of the tool is clear. I realized you merged 1 and 2 using a build step in Gutenberg so right now it's more

1- Checkout and unzip.
2- Copy built files to the right places.