Get WordPress

Make WordPress Core

Opened 4 weeks ago

Last modified 6 days ago

#64595 new task (blessed)

Update Gutenberg ref in package.json

Reported by: ellatrix's profile ellatrix Owned by:
Milestone: 7.0 Priority: normal
Severity: normal Version: trunk
Component: General Keywords: has-patch
Focuses: Cc:

Description (last modified by ellatrix)

Opening this ticket as a reference for commits. We can probably keep this open for all ref updates during this release cycle.

See also #64393.

Change History (21)

#1 @ellatrix
4 weeks ago

  • Description modified (diff)

This ticket was mentioned in ​PR #10865 on ​WordPress/wordpress-develop by ​@ellatrix.
4 weeks ago #2

  • Keywords has-patch added

Trac ticket: https://core.trac.wordpress.org/ticket/64595

​@desrosj commented on ​PR #10865:
4 weeks ago #3

Do we have a good way to track which changes (features, bugs, etc.) are being included in each ref update? Apologies if I missed it, but are we bumping to refs representing specific changes, such as releases or certain milestone completions?

Without the SVN commit messages noting what is included in each ref bump, there will inevitably be situations where tracking the introduction of certain changes is near impossible.

This ticket was mentioned in ​Slack in #core-editor by ella. ​View the logs.
4 weeks ago

​@ellatrix commented on ​PR #10865:
3 weeks ago #5

Do we have a good way to track which changes (features, bugs, etc.) are being included in each ref update? Apologies if I missed it, but are we bumping to refs representing specific changes, such as releases or certain milestone completions?

Without the SVN commit messages noting what is included in each ref bump, there will inevitably be situations where tracking the introduction of certain changes is near impossible.

We have not done this for package updates either. I think this would be good to discuss separately, I don't want it to distract from getting core updated with the latest GB changes as soon as possible.

#6 @ellatrix
3 weeks ago

In 61605:

Gutenberg ref update.

Updates unit tests to account for:

Updates the REST API posts controller's excerpt filter to account for "Post Excerpt Block: Fix length limits for both Editor and Front and fix ellipsis consistency" (​https://github.com/WordPress/gutenberg/pull/74140/changes#r2783014013).

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10865.

Props ellatrix, scruffian, desrosj.

See #64595.

---

I've included a log of the Gutenberg changes with the following command:

git log --reverse --format="- %s" 7bf80ea84eb8b62eceb1bb3fe82e42163673ca79..59a08c5496008ca88f4b6b86f38838c3612d88c8 | sed 's|#\([0-9][0-9]*\)|​https://github.com/WordPress/gutenberg/pull/\1|g; /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

Last edited 3 weeks ago by ellatrix (previous) (diff)

This ticket was mentioned in ​Slack in #meta by ella. ​View the logs.
3 weeks ago

#8 @ellatrix
3 weeks ago

Commit at https://core.trac.wordpress.org/changeset/61605, Trac is having issues displaying it, it seems.

This ticket was mentioned in ​Slack in #core by juanmaguitar. ​View the logs.
3 weeks ago

This ticket was mentioned in ​PR #10968 on ​WordPress/wordpress-develop by ​@ellatrix.
2 weeks ago #10

Trac ticket: https://core.trac.wordpress.org/ticket/64595

## Use of AI Tools

​@ellatrix commented on ​PR #10968:
2 weeks ago #11

@adamsilverstein There's an issue with the vips package:

Running "verify:source-maps" task
Warning: The build/wp-includes/js/dist/script-modules/vips/worker.js file must not contain a sourceMappingURL. Use --force to continue.

Do you know what needs to be fixed here?

​@adamsilverstein commented on ​PR #10968:
2 weeks ago #12

Not sure off hand, I'll take a look.

​@adamsilverstein commented on ​PR #10968:
2 weeks ago #13

@adamsilverstein​[[Image(chrome-extension://hgomfjikakokcbkjlfgodhklifiplmpg/images/wp-logo.png)]] There's an issue with the vips package:

Running "verify:source-maps" task
Warning: The build/wp-includes/js/dist/script-modules/vips/worker.js file must not contain a sourceMappingURL.� Use --force to continue.

Do you know what needs to be fixed here?

I asked Claude why this is failing and the explaination seemed valid:

oot Cause

The new Gutenberg ref adds the @wordpress/vips package, which uses a web worker bundle built by esbuild with sourcemap: true. This is defined in packages/wp-build/lib/worker-build.mjs:

esbuild.build({

...
sourcemap: true, adds # sourceMappingURL=... to output
...

})

The build process is:

  1. esbuild bundles the worker with sourcemap: true → produces worker.mjs with a # sourceMappingURL
  2. esbuild then re-transpiles worker-code.mjs (which embeds the worker content as a string) with sourcemap: true → adds another # sourceMappingURL
  3. webpack bundles the module entry point (vips-worker.mjs which imports worker-code.mjs etc.) into build/modules/vips/worker.js — concatenating multiple modules, each potentially carrying their own # sourceMappingURL comments

When copy-gutenberg-build.js copies this file, the removeSourceMaps function at line 894 only removes the first match because it's missing the /g flag:

const removeSourceMaps = ( content ) => {

return content.replace( /\/\/# sourceMappingURL=.*$/m, ).trimEnd();
no /g flag — only removes first match!

};

The remaining sourceMappingURL comment(s) are then caught by the verify:source-maps task in the Gruntfile, which correctly checks for any occurrence.

Notably, the existing replace:source-maps Grunt task at Gruntfile.js:1314 already uses the /g flag:
match: new RegExp( '\/\/# sourceMappingURL=.*
s*', 'g' ),

The Fix

Add the /g flag to the regex in copy-gutenberg-build.js.

I will work on a PR for this.

​@youknowriad commented on ​PR #10968:
2 weeks ago #14

I wish we could run gutenberg e2e test on these changes. I can't spot any obvious issues.

​@ellatrix commented on ​PR #10968:
2 weeks ago #15

Yes, we can look into running the e2e test on wordpress-develop, but that will add even more tests will long test times no? During the last release I kept a branch in the GB repo without the GB plugin active to double check all tests pass.

#16 @ellatrix
2 weeks ago

In 61680:

Gutenberg ref update.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10968.

Props ellatrix, adamsilverstein, youknowriad.
See #64595.

---

I've included a log of the Gutenberg changes with the following command:

git log --reverse --format="- %s" 59a08c5496008ca88f4b6b86f38838c3612d88c8..7a11a53377a95cba4d3786d71cadd4c2f0c5ac52 | sed 's|#\([0-9][0-9]*\)|​https://github.com/WordPress/gutenberg/pull/\1|g; /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

#18 @ellatrix
13 days ago

In 61705:

Gutenberg ref update.

CI run: ​https://github.com/WordPress/wordpress-develop/pull/10988.

See #64595.

---

I've included a log of the Gutenberg changes with the following command:

`
git log --reverse --format="- %s" b441348bb7e05af351c250b74283f253acaf9138..23b566c72e9c4a36219ef5d6e62890f05551f6cb | sed 's|#\([0-9][0-9]*\)|​https://github.com/WordPress/gutenberg/pull/\1|g; /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy
`

#20 @ellatrix
7 days ago

In 61750:

Gutenberg ref update.

CI run: ​https://github.com/WordPress/wordpress-develop/pull/11059.

See #64595.

---

I've included a log of the Gutenberg changes with the following command:

git log --reverse --format="- %s" 23b566c72e9c4a36219ef5d6e62890f05551f6cb..022d8dd3d461f91b15c1f0410649d3ebb027207f | sed 's|#\([0-9][0-9]*\)|​https://github.com/WordPress/gutenberg/pull/\1|g; /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

#21 @desrosj
6 days ago

I've been thinking about the commit messages for these new hash bumps and I have some suggestions for improvement to make them more useful and informative.

  • Let's make sure to begin the short description with Component: prepended. This usually should match the component selected for the corresponding Trac ticket. I'm undecided on where these tickets fit best. General feels just OK, External Libraries and Editor feels wrong. Maybe Build/Test Tools? It is a tooling change after all. I'll give this one more thought.
  • For each commit, let's include the following as the first sentence in the message: "This updates the pinned commit hash of the Gutenberg repository from OLD_FULL_HASH to NEW_FULL_HASH.
  • Instead of listing the command that was run to generate the list (git log --reverse --format. etc.), let's instead include a link to the comparison view on GitHub. For example on [61750], that would be ​https://github.com/WordPress/gutenberg/compare/23b566c72e9c4a36219ef5d6e62890f05551f6cb...022d8dd3d461f91b15c1f0410649d3ebb027207f. This is more useful because someone can click it to view all of the commits, file diffs, etc. and follow various paths to dig deeper. The command that was run is important, but that's more of a detail for committers to be aware of that can be listed in the handbook. The previous suggestion also lists out the two hashes which makes it unnecessary. How about "A full list of changes included in this commit can be found on GitHub: LINK".
  • I don't think the link to the "CI run" or "Developed in is necessary for these. The pull requests now are essentially just a hash bump, so there's really no development that happens. The commit messages for the merges are really long (which is good), but I think this detail can be left out.
  • Let's move the list of changes above the "Props" and "See/Fixes". I think I can guess why you chose to put them above the list, but I believe that they are supposed to be at the end of the commit message. It's possible there is a parsing tool somewhere that is expecting that.
  • I came to this ticket because I was looking for information about which version of Gutenberg was included in the most recent bump prior to 7.0-beta2 but noticed that is not included in the messages. It would be really great to always pin hashes that correspond to tags, and thus releases. But I recognize this may not always be desired. It would still be nice to explain how the included changes line up to those tagged versions, especially since we reference them in the beta 1 post and a few locations in the user documentation. If it lines up directly, including the version number in parentheses next to the old and new hashes could work. Otherwise, a note like "This merges all changes that were cherry-picked to the wp/7.0 branch between WordPress 7.0-beta1 and today (preparing for 7.0-beta2).

Once this is dialed in, let's add a message template for these merge commits to the Commit Messages ​Best Practices page in the Core handbook once.

Putting this all together, this is the template I think so far:

Component: Bump the pinned hash from the Gutenberg repository.

(WITH versions aligning with tags)
This updates the pinned commit hash of the Gutenberg repository from `%%OLD_FULL_HASH%%` (version `v25.0.0`) to `%%NEW_FULL_HASH%%` (version `26.0.0`).

(Without versions aligning with tags)
This updates the pinned commit hash of the Gutenberg repository from `%%OLD_FULL_HASH%%` to `%%NEW_FULL_HASH%%` and merges all of the changes that were cherry-picked to the `wp/7.0` branch between WordPress `7.0-beta1` and today (preparing for `7.0-beta2`).

A full list of changes included in this commit can be found on GitHub: %%LINK%%.

The following commits are included:
- Pattern Editing: The best pattern feature yet! (https://github.com/WordPress/gutenberg/pull/#####)
- Global Styles: Adding support for feature X within the block styles. (https://github.com/WordPress/gutenberg/pull/#####)
- etc..

Follow-up to [27195], [41062]. (optional)

Reviewed by a-fellow-committer, maybe-multiple.
Merges [26851] to the x.x branch. (both of these are only required when backporting from `trunk`)

Props person, another.
Fixes #30000. See #20202, #105.
Note: See TracTickets for help on using tickets.