Update npm packages for 6.4.2

[mikachan]

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

Included changes:

• Fix block rename control shown in "Advanced" for unsupported blocks gutenberg#55995
• Query block: remove unnecessary class gutenberg#55438
• Fix duotone not showing in site editor style block level styles gutenberg#55361
• Query Loop - Add accessibility markup at the end of the loop in all cases. gutenberg#55890
• Background Image Support: Hide the background image reset button when there's no image gutenberg#55973
• Background image support: Fix focus loss when resetting background image gutenberg#55984
• Autocomplete: Fix Voiceover not announcing suggestions gutenberg#54902
• Fix pattern category renaming causing potential duplicate categories gutenberg#55607

New published packages for this update: WordPress/gutenberg@70b30e9

---

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.

[tellthemachines]

Changes LGTM and everything works as expected in testing (I followed the testing steps for the included PRs).

One thing I'm slightly puzzled about is why all the packages are getting version bumps. Did anything change in the workflow from last release to this one? I notice this has been happening for all the updates this release, whereas e.g. for 6.3.2 only the changed packages got bumped. This is not blocking by any means 😅, just wondering about it.

[tellthemachines]

Noting that the following changes were also included in this PR:

Add check for lightbox values during image block migration

Add context for translators to any unclear usage of "synced"

Patterns: use existing download function for JSON downloads to fix no…

This is as expected because they were all marked for inclusion in the next minor release.

[tellthemachines]

Committed in r57109. Leaving this open for commit to the release branch though not sure if it's best to point this PR at the release branch instead of trunk or just open a new one (we should in any case check CI passes with this diff against the release branch)

[mikachan]

Thanks so much for helping with this and testing!

One thing I'm slightly puzzled about is why all the packages are getting version bumps.

This has been mentioned before during the 6.4 cycle but I can't find where right now. I vaguely remember it being mentioned and it was fine for now, but going into 6.5 maybe we should look more closely at this. 😅

I don't know if there's been an update to the publishing actions or if Lerna has been updated, but it's almost as if Lerna has no context for the current changes, so it assumes everything needs a version bump. I'm not sure what's changed between 6.3 and 6.4 though - maybe @gziolo knows more?

[gziolo]

After checking the publishing job I can share that I identified the reason why we still see all packages published. I landed some time ago the fix in the Gutenberg repository that potentially addresses the issue encountered with WordPress/gutenberg#55334 but it only impacts trunk. For not fully clear to me reasons, the publishing targeting the WP 6.4 release gets triggered from GitHub UI using the wp/6.4 branch. In effect, the publishing workflow doesn't use the patched version. To address it we should do two things:

• Update the docs to make it clear that publishing workflow should get triggered using the latest code from trunk.
• Cherry-pick the linked PR to wp/6.4 in case the workflow get still triggered from the branch.

It worked smoothly with WordPress 6.3 and lower. However, once Node.js and npm upgrades happened, we had to stop using the Node script and move all logic to the GitHub workflow to support all the different npm versions used with older wp branches. This is why workflow requires trunk to use the most recent version.

[mikachan]

Ah this makes sense, thanks @gziolo! I hadn't seen WordPress/gutenberg#55334.

For not fully clear to me reasons, the publishing targeting the WP 6.4 release gets triggered from GitHub UI using the wp/6.4 branch.

@SiobhyB and I discussed this early in the 6.4 cycle and we decided to go with publishing the packages targeting the wp/6.4 branch as we thought this was safer and would limit any potential unexpected issues, and we'd also seen a mix of publishing both from trunk and from the wp/X.Y branch in past runs. I guess we technically limited any issues but also missed a fix 😅

Update the docs to make it clear that publishing workflow is triggered using the latest code from trunk.

The docs screenshot does show the target as trunk, but this isn't mentioned in the text description. This sentence also threw me off: Now, the wp/X.Y branch is ready for publishing npm packages.. I had assumed this also meant "run from the wp/X.Y branch", so perhaps we could update this wording. It also didn't feel right to run the package updates from trunk, especially as all the other related work is based on the wp/X.Y branch.

Cherry-pick the linked PR to wp/6.4 in case the workflow get still triggered from the branch.

I'm happy to help handle this.

[tellthemachines]

Oh I see, thanks @gziolo !

Update the docs to make it clear that publishing workflow should get triggered using the latest code from trunk.
Cherry-pick the linked PR to wp/6.4 in case the workflow get still triggered from the branch.

I agree with @mikachan that the docs could be more explicit about which branch to trigger the workflow from, as I also found that super confusing in the past 😅
Happy to go in and change that!

Cherry picking the fix to the release branch would also be good to avoid confusing anyone packaging a minor release from this branch in the future.

[gziolo]

I cherry-picked WordPress/gutenberg@1dd3145 in the wp.6.4 branch in Gutenberg that should resolve the issue.

I agree with @mikachan that the docs could be more explicit about which branch to trigger the workflow from, as I also found that super confusing in the past 😅
Happy to go in and change that!

Let's do it as well, as it might prevent similar issues in the future. I understand how the combo box for selecting the branch might confuse people. The intention GitHub has with it is to allow the selection of the branch from which the GitHub workflow file is going to be read on CI. In effect, when selecting the wp/6.4 this is the current workflow (with the patch applied) that is going to get triggered:

https://github.com/WordPress/gutenberg/blob/wp/6.4/.github/workflows/publish-npm-packages.yml

[mikachan]

Committed in r57109. Leaving this open for commit to the release branch though not sure if it's best to point this PR at the release branch instead of trunk or just open a new one (we should in any case check CI passes with this diff against the release branch)

@tellthemachines, you mentioned above that we may either need to point this PR at the release branch (I guess this is 6.4?) or open a new one. Which one would you recommend?

Also, we have one more change that needs to be included in the package update. I'm in the process of updating the packages again here - should I create a new PR for this, or include it in this PR? I know this PR has already been committed to trunk, so I'm guessing it's best to open a new PR.

[tellthemachines]

Also, we have one more change that needs to be included in the package update.

@mikachan in that case it's probably easier to open a new PR for trunk with that extra change, and then assuming it's all good, open a third PR for the release branch including all the changes.

[mikachan]

in that case it's probably easier to open a new PR for trunk with that extra change, and then assuming it's all good, open a third PR for the release branch including all the changes.

Will do, thank you!

[mikachan]

Here's the new PR for trunk with the single extra change: #5696

The tests seem good, although it looks like there's an error with the Playground build process here. I'm not sure if that's a blocker or not.

I went ahead and created a PR against the release branch too with all the changes: #5698. All the tests passed here.

Thanks so much for your help 🙇

[mikachan]

I'm going to close this PR as these changes have already been committed to trunk in r57109. We have multiple PRs open for the npm package update (including a separate PR for the release branch), so trying to reduce any confusion!