NPM releases back in town

Open derberg opened this issue 1 month ago • 5 comments

Overview

tl;dr this happened: https://www.asyncapi.com/blog/shai-hulud-postmortem

NPM Publishing Changes

Effective immediately, the only way to publish NPM packages to @asyncapi scope, will be through Trusted Publishing.

In other words this means the only trusted publisher that can publish to NPM registry is GitHub Actions. Configuration is done per NPM package by the AsyncAPI Governance team. Explicit settings provided in NPM config are:

name of the repository and organization that publish the package
name of the workflow file that is responsible for pushint the package

Example: @asyncapi/web-component can be released only by GitHub Actions that run in asyncapi-react repository as part of release-wc-and-playground.yml workflow. This means that any repository renaming, or project move because of monorepo setup, or workflow rename must be reflected in NPM package settings.

At the moment proper configuration is already in place for all the AsyncAPI packages.

Must Have Requirements

Release Pipelines Based on Semantic Versioning

If your workflow name is if-nodejs-release.yml and first line says #This action is centrally managed in https://github.com/asyncapi/.github/ you have the latest workflow version already in your repo.

Your only requirement is to release next major version (breaking change) where you explicitly define that project works only with >=22. This is needed as we had to use latest [email protected] that depends on node 22.

Node version 20 in in maintainance mode only until April so this should not be a problem. If you have strong business reasons to not enforce versions 22 and up, you will have to manage your release pipelines on your own with some workaround that we are not aware of. This is not recommended.

This is what you need to add in your package.json file:

"engines": {
    "node": ">=22.14"
}

You can also manipulate version of the Node that should be used in workflows through GitHub repository settings but adding NODE_VERSION environment variable. Read more in https://github.com/asyncapi/.github/tree/master/.github/actions/get-node-version-from-package-lock

Release Pipelines Based on Changeset

We have few monorepo projects using Changeset for releases. These workflows are not managed centrally in .github repo, therefore you need to update them manually.

Most important requirement is to release next major version (breaking change) where you explicitly define that project works only with >=24. Yes, version 24 and above, because of requirement to use npm 11 which is not working well with node 22. NPM 11 is also a requirement specified in NPM official docs.

If you have strong business reasons to not enforce versions 24 and up, you will have to manage your release pipelines on your own with some workaround that we are not aware of. This is not recommended. Changeset owners did not address Trusted Publishing yet. You can of course manually modify only the release step and make only release step use node 24 while still test on different version.

This is what you need to add in your package.json file:

"engines": {
    "node": ">=24.11"
}

Below picture shows what I had to change in the generator repository:

update macos image (not release related, you still have to do it for other deprecation reasons)
add registry-url: "https://registry.npmjs.org" in setup node step
add reading of node version from environment variables repository settings in step where we use our own get-node-version-from-package-lock composite action"
```
with:
    node-version: ${{ vars.NODE_VERSION }}
```
remove NPM_TOKEN: ${{ secrets.NPM_TOKEN }} as we no longer use tokens

add proper permissions in release job:

permissions:
  contents: write
  id-token: write
  pull-requests: write

Also here is how I use NODE_VERSION feature in generator

Dec 04 '25 16:12 derberg