Feat: Npm provenance setup

[Totto16]

Similar to gjsify/gnome-shell#64

@JumpLink already knows what to setup and how provenance works.

So a few details on how this PR solves this.

You don't make releases here on GH, as you publish many packages in one commit and making a release for everyone here is not needed, as the releases (versions) are made on npm.

So this executes a GH action on every push to main, it executes this in the environment (npm-release)

It than builds and executes the script in .github/release-script.

That script does these things:

• it searches all package,.json files (except the one for that script)
• it extracts the data (name and version) from the package files for each package file
• it checks npm, if the version of the package.json is already published
• if it is, it does nothing for this package
• if it isn't published yet, it uses npm publish ... --provenance to publish the package with that version to npm with provenance

It needs access to the NPM_TOKEN, like in gjsify/gnome-shell#64

As provenance is now standardized and npm + GH make it available, it would make sense, to publish all packages with provenance.

I tested this script with my own private repo (without provenance) and it works, as we use raw npm here and not yarn as in gjsify/gnome-shell#64 there is no need for an additional fix like in gjsify/gnome-shell#71

Feel free to ask any questions regarding the script 😄

(It would also make sense, to test it on the next release of these types with only one package at a time, but we would need to hardcode something for that)

[JumpLink]

@Totto16 Thank you very much for this – it looks great to me!

I just have one change request: could you execute the TypeScript script directly with Node.js >= 22 using the following command?

node --experimental-specifier-resolution=node --experimental-strip-types --experimental-transform-types --no-warnings .github/release-script/src/index.ts

That way, we can skip the build step entirely.

PS: I'm also open to completely dropping yarn in gjsify/gnome-shell. Since we only have one package there, we actually don’t need it. I initially set it up that way because I generally find it helpful for workspaces with multiple packages – but I also really value keeping things as simple and minimal as possible.

[Totto16]

@Totto16 Thank you very much for this – it looks great to me!

I just have one change request: could you execute the TypeScript script directly with Node.js >= 22 using the following command?

node --experimental-specifier-resolution=node --experimental-strip-types --experimental-transform-types --no-warnings .github/release-script/src/index.ts

That way, we can skip the build step entirely.

PS: I'm also open to completely dropping yarn in gjsify/gnome-shell. Since we only have one package there, we actually don’t need it. I initially set it up that way because I generally find it helpful for workspaces with multiple packages – but I also really value keeping things as simple and minimal as possible.

Yeah of course I can use node directly 👍🏼

[schnz]

Hey guys,

despite my lack of participation in the recent activities, I closely followed all the conversations and PRs. Thanks for all the effort you put into this!

I initially set it up that way because I generally find it helpful for workspaces with multiple packages – but I also really value keeping things as simple and minimal as possible.

Fun fact: Last Friday I converted a TypeScript based npm package to a split-package (with a core package + multiple plugins). I tried npm workspaces for the first time because I also wanted to avoid additional tooling such as lerna, yarn, etc. Just wanted to say: It's working flawlessly - so unless yarn offers something additional to that, npm might suffices for these kind of projects.

[JumpLink]

@Totto16 I’ve now set up the npm-release environment with the NPM_TOKEN secret configured and restricted deployments to the main branch. Workflow permissions were already set to Read/Write, so that part was fine.

I didn’t add a global NPM_TOKEN, since everything runs through the environment anyway.

So this should be ready to go, feel free to let me know once you’re done on your side.

[Totto16]

@Totto16 I’ve now set up the npm-release environment with the NPM_TOKEN secret configured and restricted deployments to the main branch. Workflow permissions were already set to Read/Write, so that part was fine.

I didn’t add a global NPM_TOKEN, since everything runs through the environment anyway.

So this should be ready to go, feel free to let me know once you’re done on your side.

Then everything should be ready, I already have tested this, and the node change is already done. So on my side everything is ready 😄

[JumpLink]

@Totto16 Great, then I'll merge it and test it as soon as I'm done with gjsify/ts-for-gir#281 :)

[Totto16]

@JumpLink I just saw, that you published https://github.com/gjsify/ts-for-gir/releases/tag/4.0.0-beta.35

And the script doesn't really seem to work 😓 d73e113 - 41c3a74

I don't have time yet to look into it yet, but do you need help or is it a problem with something other than provenance e.g. npm rate-limiting us?

[JumpLink]

@Totto16 Yes, that was also my assumption, which is why I included waiting times, etc. I'll try it out a little more.

[Totto16]

@Totto16 Yes, that was also my assumption, which is why I included waiting times, etc. I'll try it out a little more.

According to https://docs.github.com/de/actions/tutorials/publish-packages/publish-nodejs-packages

You also need the scope setup correctly, when uisng the action

        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.node-version }}
          registry-url: 'https://registry.npmjs.org'

so add this

          scope: '@girs'

IIRC i also had this for the gnome-shell types, and without it, it wouldn't work correctly, as the action assumes @gjsify

🤔

[JumpLink]

@Totto16 I completely forgot that the yarn syntax workspace:^ is used for the version of dependencies in the package.json files. I suspect that is the issue. yarn automatically resolves this when yarn npm publish is used and writes the version from the workspace there. I suspect that is the issue.

[Totto16]

@Totto16 I completely forgot that the yarn syntax workspace:^ is used for the version of dependencies in the package.json files. I suspect that is the issue. yarn automatically resolves this when yarn npm publish is used and writes the version from the workspace there. I suspect that is the issue.

So maybe you need to replace npm publsih with yarn npm publish in the script, but then its the same as in gjsify/gnome-shell#71 as yarn expects other env variables (at least I think) and needs more configuration 🤷🏼‍♂️

[JumpLink]

@Totto16 ts-for-gir offers the option of creating packages without the workspace:^ syntax. My current plan is to automatically execute an action during a ts-for-gir release that creates the packages without the workspace version string and pushes them to types. This way, we would have both automated

[Totto16]

@Totto16 Yes, that was also my assumption, which is why I included waiting times, etc. I'll try it out a little more.

According to https://docs.github.com/de/actions/tutorials/publish-packages/publish-nodejs-packages

You also need the scope setup correctly, when uisng the action

        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.node-version }}
          registry-url: 'https://registry.npmjs.org'

so add this

          scope: '@girs'

IIRC i also had this for the gnome-shell types, and without it, it wouldn't work correctly, as the action assumes @gjsify

🤔

@JumpLink

e38963c still fails 🤔

maybe really add the scope to the release.yml file 🤔

[JumpLink]

@Totto16 Thank you, unfortunately that doesn't seem to help either :(

[Totto16]

@Totto16 Thank you, unfortunately that doesn't seem to help either :(

I saw it in https://github.com/gjsify/types/actions/runs/17106463430/job/48516564860

What is the problem, the error logs are not really helpfull IMO 🤔

[JumpLink]

@Totto16 I'm giving up for today. I've given you access to the repo. If you feel like it and have time, you might be able to find the problem 🤯

[JumpLink]

@Totto16 Oh my God, I think I have that problem, wait a minute...

[JumpLink]

@Totto16 It was the wrong token 😭

[Totto16]

@Totto16 It was the wrong token 😭

🤦🏼‍♂️ 😭

At least it works now 👍🏼

[Totto16]

@JumpLink
Now we get rate limit 😂

https://github.com/gjsify/types/actions/runs/17108728370/job/48524379504

Edit:

We also get this warning in all (presumably) packages: npm warn publish npm auto-corrected some errors in your package.json when publishing. Please run "npm pkg fix" to address these errors.

Ah it also says:

npm warn publish errors corrected:
npm warn publish "repository.url" was normalized to "git+https://github.com/gjsify/types.git"

[JumpLink]

@Totto16 Thank you

@JumpLink Now we get rate limit 😂

https://github.com/gjsify/types/actions/runs/17108728370/job/48524379504

Edit:

We also get this warning in all (presumably) packages: npm warn publish npm auto-corrected some errors in your package.json when publishing. Please run "npm pkg fix" to address these errors.

Ah it also says:

npm warn publish errors corrected:
npm warn publish "repository.url" was normalized to "git+https://github.com/gjsify/types.git"

Thanks, I re-ran the action and then the remaining packages were published. Thanks for pointing out the URLs, I'll fix that.