What

Related PR with manually triggered npm publishing: #37751.
Related discussion: #37820.

I'm proposing a new strategy where the "feature-freeze" mode in WordPress Core isn't taken into account when publishing npm packages with the latest tag. The plan is to publish to npm every time the Gutenberg plugin RC1 is released.

After a release of WordPress, we need to leave room for patch releases and security releases (so patch versions changes).

Every plugin release (RC1) will trigger at least a minor version bump for packages with production code. I also want to automate adding a CHANGELOG entry that links to the GitHub release page with the full plugin release changelog.

During the beta/rc cycle of WordPress, we often need to make package updates that are not necessary just bug fixes, so minor version changes, we should make sure there's no "newer" version available because of a plugin npm release.

As long as those changes are applied as a patch version bump then it should be good for the time being. An alternative to consider as a follow-up would be to enforce a major version bump to production packages on the plugin release that won't be included in the upcoming major WordPress release. The latter is more difficult to handle but I think @ockham had some ideas on how to detect this exact moment.

The only non-blocking remaining question is whether we would use patch dist-tag for beta and RC phase of major WordPress releases or we switch to tags targeting a given release line as discussed in #37820 (reply in thread). In the case of the upcoming WordPress 6.0 release, we could start using wp-6.0 tag instead. This proposal is tracked in #24376.

In the long run, we could simplify npm publishing for minor WordPress releases (like 5.9.x) so you could trigger it from the GitHub UI using similar automation that we have for plugin releases. For the time being, the changes proposed in this PR don't impact this type of releases at all.

Why

We have GitHub automation in place for handling the Gutenberg plugin releases.

Prior work:

• #27488
• #28138

We should bring the same experience when publishing WordPress packages to npm to make the whole process predictable and more transparent.

npm publishing is still a manual process that has its quirks when the WordPress trunk branch can be closed or in "feature-freeze" mode as documented in Synchronizing WordPress Trunk. There is also a limited group of folks who have access to WordPress organization on npm. It's a lot of overhead to add new contributors there and train them.

How

npm access token

I created a new npm user gutenbergplugin that mirrors the @gutenbergplugin user that handles the Gutenberg plugin releases on GitHub.

I followed the instructions from npm documentation to create an access token for npm publishing:

https://docs.npmjs.com/creating-and-viewing-access-tokens

I followed the instructions from the following article on how to configure a GitHub action to perform npm publishing with the token:

https://dev.to/astagi/publish-to-npm-using-github-actions-23fn

As part of that, I went to "Settings" -> "Secrets". I clicked on "New repository secret" and added the npm access token that I previously copied from npm. It's available in GitHub actions as secrets.NPM_TOKEN whenever you want to use gutenbergplugin for automated npm interactions.

This way npm publishing triggered from GitHub actions will always use a bot user instead of private accounts. It removes all the friction of managing the WordPress organization on npm 🎉

GitHub workflow

I added a new job in the workflow that handles Gutenberg plugin releases. It is going to be triggered:

• when the Gutenberg plugin RC1 is created
• after the changelog for the Gutenberg plugin gets updated

The job for the first test run will publish WordPress packages to npm based on the plugin release with the next dist-tag. That means we won't update the production version of npm packages but those distributed for development purposes. This is intentional to minimize the risk that something goes wrong.

Testing instructions

I don't think there is a simple way to test those changes without triggering a real Gutenberg plugin RC1 release.

I tested it in a very hacky way by injecting the job into the Static Analysis workflow that gets triggered on every commit to the PR. You can check the last testing version in f74fdf3. I was able to successfully publish all WordPress npm packages to npm with the next dist tag:

All the following changes to the wp/next branch got applied from testing runs triggered from this branch:

It took me some time to sort out npm access permissions when interacting with Lerna. The commit related to the successful publishing is c510818.