Impact of the publication of npm package to registries in xwiki-platform

Development
,
1

While my work to be able to publish npm packages from xwiki-platform modules is still ongoing, I’d like to highlight the impacts I already identified to make them known to all of you as soon as possible.

Impact on the CI

A technical user will need to be registered on the agents to allow the automated publication of snapshot versions (see Impact on Maven below).

Impact on the release

xwiki-dev-tools/maven-release.sh

We’ll need to change package.json version on the pre/post steps.

pre_update_parent_versions/post_update_parent_versions will be replaced by more generic functions (e.g., pre_update__versions/post_update__versions) that will call *_update_parent_versions + a new *_update_npm_packages_versions that will patch the package.json versions.

During the release

  • Committers will be requested for an npm token to be able to push the artifact to https://www.npmjs.com/
  • Committers will need to be part of the xwiki npmjs organization (with sufficient rights). From previous discussions, I understand that we do not want to share a generic account to publish artifacts (at least @tmortagne mentioned this to me, but I can’t find the forum discussion).

Impact on Maven

I propose to add a small JavaScript script that would be called during the deploy phrase through the frontend-maven-plugin. Its logic would be the following:

  • check for the presence of SNAPSHOT in the version
    • if true
      • replace SNAPSHOT by the current timestamp (e.g., date +%s).
      • call pnpm publish --registry ${xwiki.npm.snapshot.registry} --tag snapshot --no-git-checks
    • if false: call pnpm publish --registry ${xwiki.npm.release.registry} --access public

With:

Impact on Cristal

For Cristal this means that some packages will not be part of the workspace anymore.

Cristal developers will need to use Sonatype Nexus Repository as the main registry during development.

This also means that code change will not be as instantaneous as it used to be.
In development, all the @xwiki-platform-* packages will have a ^${next-stable-XS-version)-0 version.
Calling pnpm upgrade will update the version with the most recent timestamp.
During the release, ^${next-stable-XS-version)-0 will be replaced by ${next-stable-XS-version) using the https://registry.npmjs.org/ registry to make sure to have reproducible builds.

Impact on Nexus

This part is not fully sorted out, but we’ll need to add a script to clear deprecated snapshot versions, as it does not make sense to keep old snapshot artifacts forever.

I’ll update this discussion if I identify new impacts when working on the topic.
Meanwhile, please let me know what you think.
Thanks.

1 Like
2

Actually we do use common credentials to deploy artifacts on Maven central. The difference is on the signing of those artifacts.

What I mentionned to you is Use the same GitHub account and GPG key for all XWiki Standard releases, so more the github and signing side of things.

We are using standard Nexus schedulers for that kind of cleanup, but if the concept of SNAPSHOT does not exist in npm Nexus support, I guess there is nothing like this out of the box.

3

Not sure to understand this? We deploy snapshots to our own nexus repo ok. But in case of release we deploy the release artifacts to a server hosted on the release machine?

4

Bad copy-paste… The right value is https://registry.npmjs.org/

5

So here too?

6

Yes, fixed as well.

1 Like
7

See the currently opened PRs: