Github workflows: extend package changelog nudge to bundled packages

[simison]

What?

Extends the changelog nudge GitHub action to include all bundled packages, plus private-apis and wp-build packages.

Why?

Follow-up to the previous config consolidation done in #78169

Bundled packages

These packages are bundled and referenced as window.wp globals, and follow Semantic Versioning. It's important that downstream consumers are kept informed about changes that might impact their usage of the package. The likelihood of breaking changes is greater since bundled packages are often experimental, and we don't need to be as careful with backwards compatibility; consumers update versions at will at their own pace.

WP Build and Private APIs

Extending with WP Build came up in #78807 (comment) after updating some missing changelog entries from wp-build package.

Consumers are starting to use WP Build, and can control when they update the version; it's not a runtime library externalised, but a command-line tool instead. The tool is at a fairly early stage, so it's important to communicate well about any changes within it.

Additions in private APIs, particularly when used in bundled packages, can cause mismatched version expectations when used with WP Build: bundled packages can try to depend on unlocking an API in externalised window.wp.* packages with a version of private APIs that doesn't yet list the permissions for the unlock. (See #75987)

How?

Just extends the existing list.

Testing Instructions

Github actions pass.

Use of AI Tools

[simison]

The list:

gutenberg/packages/dependency-extraction-webpack-plugin/lib/util.js

Lines 2 to 14 in 727142a

	const BUNDLED_PACKAGES = [
	'@wordpress/admin-ui',
	'@wordpress/dataviews',
	'@wordpress/dataviews/wp',
	'@wordpress/fields',
	'@wordpress/grid',
	'@wordpress/icons',
	'@wordpress/interface',
	'@wordpress/style-runtime',
	'@wordpress/ui',
	'@wordpress/undo-manager',
	'@wordpress/views',
	];

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

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: simison <simison@git.wordpress.org>
Co-authored-by: retrofox <retrofox@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[github-actions]

Flaky tests detected in 3f9625a.
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/28814458875
📝 Reported issues:

• [Flaky Test] can use appender in site editor sidebar list view #79632 in /test/e2e/specs/site-editor/navigation-sidebar-list-view.spec.js
• [Flaky Test] shows post-locked modal when document size limit is exceeded #78753 in /test/e2e/specs/editor/collaboration/http-only/collaboration-document-size-lock.spec.ts

[aduth]

I sense the answer is a reluctant "yes", but do we still maintain @wordpress/dependency-extraction-webpack-plugin? At the very least, I think the way I'd think we should document this expectation is around our current thinking with wpScript / wpScriptModule and how that's handled through @wordpress/build. And if we intend to maintain @wordpress/dependency-extraction-webpack-plugin, it should probably be updated to use those same indicators instead of including a hard-coded list. A related thought I had is that if we wanted to keep this in sync, we could do some sort of CI inception to force-keep it in sync 😂 (something like #76263)

[simison]

Yeah, I don't think we're moving away from @wordpress/scripts either super soon (or at least we need to maintain it for now).

That said, I think we could move to read package.json files in dependency-extraction-webpack-plugin too instead of the hardcoded list. Actually, it would make it so that the version of dependency-extraction-webpack-plugin doesn't depend on matching specific versions of those bundled packges; the package itself tells if it should be bundled or not.

I also want to be transparent to consumer what gets bundled and what externalized, because it really affects a lot how careful they need to be when updating dependency versions. Doing that in https://github.com/WordPress/gutenberg/pull/79634/changes#diff-ed1ee7b58dba4945d02b57bbde06ff95123fc15955ae2d760f1707b00b22fb56 but later iterations could change how we expose the info.

For now I just want to make sure changelogs are updated within the setup we have today, and we can improve the setup outside this PR.

[aduth]

undo-manager isn't a bundled package, is it? It has wpScript: true:

gutenberg/packages/undo-manager/package.json

Line 43 in 4d0fdbe

"wpScript": true,

[aduth]

I guess per your other comment it's consistent with what's in the Webpack plugin, but now I'm confused why it's there 🤔

[aduth]

It turns out to be a fun little rabbit-hole.

The package was originally intended to be "bundled", as mentioned in @youknowriad 's comment #54292 (comment).

As part of shifting to npm workspaces in #65681 / #66272, wpScript was added to packages that are shipped as WordPress globals. At the time, per @sirreal 's comment at #65681 (comment), I believe this was largely meant for license check purposes only. wpScript was mistakenly added to @wordpress/undo-manager.

The @wordpress/build package added in #72032 used wpScript to detect whether to create the WordPress global. Some packages were revised as part of this work to remove wpScript (icons and interface in #72319), but undo-manager kept it.

Thus, we now have a state where @wordpress/undo-manager is shipped as a WordPress global window.wp.undoManager in WordPress 7.0 (confirmed locally), despite originally intended to be a bundled package.

In any case, not really a blocker for this pull request in particular, but we'll need to figure out what we want to do with this package.

[retrofox]

I did some archaeology, and the entry is simply stale: undo-manager was added to BUNDLED_PACKAGES in #54292 (September 2023), when the package had just been extracted from core-data and wasn't yet a core script.

It later became one ("wpScript": true today), but it was never removed from the hard-coded list. It's the only package of the ten in that list with wpScript: true; the other nine have it absent or false.

For this PR, the grouping is cosmetic; the check behaves the same regardless of where the package sits.

The real fix would be removing undo-manager from BUNDLED_PACKAGES in dependency-extraction-webpack-plugin, but that changes what consumers bundle vs externalize, so it deserves its own PR.

Which also reinforces the point you both made: deriving this from package.json flags would have prevented the drift in the first place.

[simison]

Nice sleuthing!

Opened PR to continue there:

• Dependency extraction webpack plugin: use package.json wpScript value to determine bundling #79945

[retrofox]

I reviewed the diff and cross-checked the two lists: the paths filter and the job matrix remain 1:1, and the "Bundled packages" group exactly matches BUNDLED_PACKAGES in packages/dependency-extraction-webpack-plugin/lib/util.js.

I think the check logic itself doesn't change here, and it's already been running on trunk for the four packages covered today, so extending the list feels low-risk.

[aduth]

We'll eventually need to follow-up on my comment from #78934 (comment), but it's not a blocker for this, and if we similarly plan to refactor to use package.json as the source of truth, this workflow doesn't need have to directly deal that inconsistency anyways.

[aduth]

Something I've noticed is this creates quite a bit of noise in the checks summary, since each package is listed individually. I had come to appreciate this since it's clear from the check name which package needs corrections, but with as many packages as we're checking now, it's a bit excessive. I also worry this might be causing jobs to queue if they're run individually, although each should be pretty quick.