Github workflows: extend package changelog nudge to bundled packages#78934
Github workflows: extend package changelog nudge to bundled packages#78934simison wants to merge 2 commits into
Conversation
simison
added
[Tool] Dependency Extraction Webpack Plugin
| package: | ||
| - components | ||
| # Bundled packages | ||
| # Keep in sync with dependency-extraction-webpack-plugin |
There was a problem hiding this comment.
The list:
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| - 'packages/dataviews/**' | ||
| - 'packages/ui/**' | ||
| - 'packages/fields/**' | ||
| - 'packages/grid/**' |
There was a problem hiding this comment.
We could leave Grid out for now since it's still private package and not published to NPM. But not a biggie to have it, and a good habit to keep the changelog up-to-date.
There was a problem hiding this comment.
Yeah, it feels a little weird if our audience for changelogs is consumers that we'd be writing a bunch of changelogs for things that don't ever reach someone until the big "initial release" that's accompanied by a bunch of seemingly-irrelevant changelog notes. But to your point, if it wouldn't bother people maintaining this package, it's good to build that muscle memory.
|
Flaky tests detected in 48f4b97. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26937792078
|
| - 'packages/dataviews/**' | ||
| - 'packages/ui/**' | ||
| - 'packages/fields/**' | ||
| - 'packages/grid/**' |
There was a problem hiding this comment.
Yeah, it feels a little weird if our audience for changelogs is consumers that we'd be writing a bunch of changelogs for things that don't ever reach someone until the big "initial release" that's accompanied by a bunch of seemingly-irrelevant changelog notes. But to your point, if it wouldn't bother people maintaining this package, it's good to build that muscle memory.
| package: | ||
| - components | ||
| # Bundled packages | ||
| # Keep in sync with dependency-extraction-webpack-plugin |
There was a problem hiding this comment.
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)
2 participants
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.wpglobals, 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