Investigate options for registry cleanup

[arboleya]

This is a follow-up issue after #2377

When someone runs npm info fuels, the output is far from ideal:

Click for screenshot

The solution to this would include two steps:

• Contact NPM support to remove all irrelevant tags
• Deprecate irrelevant tags
• Stop publishing temporary tags to NPM

The ability to publish temporary PRs is helpful, but it'd be great if we could do that separately from the NPM registry.

Could we use GitHub packages to resolve the second point?

• https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages

Ideally, we'd still be able to publish temp tags while keeping our packages clean and tidy.

[petertonysmith94]

@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.

[arboleya]

@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

[arboleya]

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

[danielbate]

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.

[arboleya]

Easy, just 21k+ versions. 😅

[danielbate]

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.

[danielbate]

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

[danielbate]

@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?

[arboleya]

@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.

[danielbate]

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.