@danielbate I think the second point here is super valuable, as it'd enable us to run the UI integration tests by default, and not only on merge to master.

@danielbate The reference script/workflow I mentioned:

• https://github.com/FuelLabs/fuels-npm-packs/blob/main/scripts/unpublish.js
• https://github.com/FuelLabs/fuels-npm-packs/blob/main/.github/workflows/unpublish-npm.yaml

Also, here's the NPM policy:
https://docs.npmjs.com/policies/unpublish

I have contacted support to remove the following versions, let's see how it goes. Worst case scenario we can alter the script and deprecate these versions.

Easy, just 21k+ versions. 😅

Okay so unfortunately support cannot remove our versions... Our weekly download count is too high and we have too many dependents.

I'm going to make an adjustment to the script so that it deprecates these versions rather than attempting to un-publish. I'd also favour having it run on a cron whilst we go through this process.

I'll also look to move future published PR versions to a seperate registry.

Deprecation will clean up info alot, this is the result for nextjs who have more published versions than us, but deprecate.

@arboleya I've investigated using a private registry and it certainly is possible. However one reason we use PR versions is for testing with consumers. Using a private/separate registry will require the consumer to configure the .npmrc file to load from the registry.

I think this problem could be mitigated if we just correctly and regularly deprecate versions. Once #3465 is through I'll make a change so we can pass singular versions, and maybe even a cron that cleans up versions every few days (but I'm not sold on the latter as consumers take time to respond). Do you think this would suffice, or still prefer a separate registry?

@danielbate Could we deprecate a specific tag when the related PR goes to master?

Can custom registries be specified as a CLI option or just as a .npmrc config?

npm install abc --registry=xyz

Either way, it's perfectly fine to move in small increments here.

We can start with deprecation and still consider possible future improvements.

Could we deprecate a specific tag when the related PR goes to master?

Yes exactly my thoughts. So on a feature PR merge, we could deprecate any associated pr release tags. On a release PR merge, we deprecate any previous next release tags. I definitely think there's room for automated deprecations to manage this.

AFAIK it's only via the npmrc for a custom registry on install, but I will see.

@danielbate We will stop publishing non-tag versions to NPM, effective immediately. For temporary and non-tagged releases (pr-*, next), we must use another registry like GitHub. Bumping priority on this.

Makes sense. Given the increase in priority I've unassigned my self for now. Hopefully it can be picked up sooner by either @petertonysmith94 or @nedsalk?

@arboleya I've been exploring using GitHub packages as a registry option (#3639).

To enable publishing, we must make many changes to our package names in package.json, changesets, etc., to include the organisation scope (FuelsLab/) — see the scope here.

A better option might be using AWS CodeArtifact, which should reduce this complexity and be more in-sync with the actual release process to NPM.

Great job, man! Record time. 👏

I don't see anything wrong with Github - do you?

I think the flow would look something like this:

---
title: Release Flow
---
flowchart
  PR([PR #4876]) --> Master(master)
  PR --> |‎ ‎ pr-4876‎‎ ‎ | GH
  Master --> IsRelease[[is this a release?]]
  IsRelease --> Yes(yes)
  IsRelease --> No(no)
  Yes --> Wait[/manual approval/]
  Wait --> |‎ ‎ latest‎‎ ‎ | Npm{NPM}
  No --> |‎ ‎ next‎‎ ‎ | GH(((GitHub)))

Great job, man! Record time. 👏

I don't see anything wrong with Github - do you?

I think the flow would look something like this:

I'm happy with GitHub for now.

I've implemented a workflow based on your diagram in #3639. The manual approval will still be required at the moment - we will need to separate the workflow into two jobs:

• Release + publishing to GitHub
• Publishing to NPM

We have managed to deprecate all our 0.0.0-x versions on the following action:

• https://github.com/FuelLabs/fuels-ts/actions/runs/13184120371/job/36802008166#step:6:42

We deprecated all our dist-tags on the following action:

• https://github.com/FuelLabs/fuels-ts/actions/runs/13200027381

Using the following PR:

• chore: fix deprecate versions #3670

We've have a PR to integration GitHub packages:

• chore: migrate pr + next package publishing to GitHub Packages #3639

I've created an issue to enhance this workflow further:

• Consider automating package publishing on every PR #3671