Build: Restore removed files from Gutenberg build change.

[dmsnell]

Trac ticket: Core-64393

When [61438] changed how the Gutenberg build was merged into Core, it removed all of the existing files which exist on both sides of the project.

The goal of this additional change was to force a single source of truth for those files. Unfortunately, there is considerable value in having those files in the wordpress-develop repo, even though from time to time there are minor inconveniences from having them exist in both places.

• Comparing how the files changed from one release to the next.
• Debugging changes and bisecting project history to discover where a bug appeared.
• Checking out different commits without network access, without downloading almost 2 GB of data, without spending minutes waiting for files to build and still being able to use WordPress on a local checkout.
• Benchmarking along various commits.

Thankfully, the change was entirely unnecessary to accomplish the goal in the Trac ticket, so reverting the deletion of all of these files, and removing the .gitignore entires, leaves everything about the build change in place while mitigating the long-term impact on the project history.

Unfortunately, most git tooling will forever fail when looking at the history of these files. There is no way to restore the continuity of changes over time once they have been deleted and added to .gitignore, so this is a disappointing mitigation at best, but if it merges into 7.0 then at least we will be able to review all of the changes from one version to the next, with a command like git diff 6.9.1..7.0 -- src/wp-includes/blocks

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

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @1178653+wordpress-develop-pr-bot[bot]@users.noreply.github.com.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Props dmsnell, youknowriad.

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

[dmsnell]

blocked by WPCS. @youknowriad can you advise here? I don’t understand the role of the removed script loader files but I think they are tripping up when trying to re-add them

[youknowriad]

Personally, I think this PR doesn't make sense.

Comparing how the files changed from one release to the next.

This can be done on WordPress/WordPress repo if needed.

Debugging changes and bisecting project history to discover where a bug appeared.

This can still be done, it will result in the "hash" upgrade that introduced the issue, which mean you'll have the exact Gutenberg hash used in Core where the issue started happening. If you want to go deeper, you can go into gutenberg, check the changelog or bisect there. Exactly like we do with any npm dependency version upgrade

Checking out different commits without network access, without downloading almost 2 GB of data, without spending minutes waiting for files to build and still being able to use WordPress on a local checkout.

The same thing can be said for any npm version change, there's no difference with keeping these files or not, half of the files was still not in Core before the change.

---

Personally, I think seeing these files changes in PRs is a problem, it hides the purpose of the PR (upgrade a dependency) with additional changes that implementation details. When you update a npm or composer dependency, you're not going to look at all the files changed that happened in that dependency.

[youknowriad]

The issue we're seeing in some of the failures on this PR is also one of the things that I think shows why the addition of these files to .gitignore is the right move.

Basically we're forced to ensure that whatever is committed is exactly the same files that are generated when npm install runs, so running npm install shouldn't result in a git diff. Right now in this PR it does because the formatting of some of these files that you committed doesn't match the expectations of the php unit tests.

---

I can't tell what all the other failures are about.

[dmsnell]

thanks for your help @youknowriad — I do understand your view here; I’m just trying to preserve the changes you wanted while restoring a collection of broken flows.

the presence of these files should not break anything, unlike how their removal has.

Basically we're forced to ensure that whatever is committed is exactly the same files that are generated when npm install runs, so running npm install shouldn't result in a git diff.

And yeah, this is an additional guard that will/would alert us to any changes that occurred if we do get a diff from the process.

I will see if maybe I hit some issue which caused the formatting to be off.

[youknowriad]

the presence of these files should not break anything, unlike how their removal has.

I'd say that the presence of these files break the flow of making PRs on WordPress develop for Gutenberg updates. It results in huge PRs that are mostly generated files that don't need to be part of my PR. The same way when I update an npm package, I don't want to see the diff on that npm package in my PR.

I don't understand why we have two different flows for the same concept depending on whether it's an "npm package" or a "git package".

[dmsnell]

This is more challenging than I hoped, beyond simply marking the files as binary. There is a complication that I don’t know if some of the issues I’ve hit are because I’m adding these files back in this same PR where their metadata is being changed.

It’s possible that this would be smooth were it to merge. Nonetheless, I have marked these files as auto-generated and wrote a script to use for ensuring that non-auto-generated files are not changed.

The changes will still be visible if someone wants to see them, and they show up in git status, but the CI jobs will overlook them. I think this matches what we want. We essentially only want those files to be updated when changing the Gutenberg hash, and those changes should be checked in. If they are ever modified otherwise we just want to ignore that.

I do think that this extra work with git attributes is probably unnecessary and all we need to do is just add the files back and then things would work, but this is continuing the experiment to see how far we can go with the problem:

Track these files and commit their changes when changed, but ignore updates that aren’t intentionally added.