npm package storage: 590 versions, ~12GB — risk of policy action

[melvincarvalho]

Problem

The mashlib npm package currently has 590 published versions totaling an estimated ~12GB on the npm registry (each build is ~21MB unpacked).

The growth has accelerated sharply:

Year	Versions published
2023	23
2024	10
2025	90
2026 (Jan–Feb only)	109

That's 199 versions in ~14 months, compared to 10 in the entirety of 2024.

Risk

npm monitors package storage and has taken action against packages for excessive registry usage. With 14 maintainers listed on this package, a policy action would affect everyone.

Suggested fixes

1. Add a version-exists check to CI so it doesn't publish if the version already exists on npm
2. Stop publishing prerelease/hash versions (e.g. 2.1.4-test.0, 3.0.1-0dd33a6) to the public registry — use a local artifact or GitHub Packages instead
3. Consider deprecating the hundreds of unused prerelease versions to signal they are not intended for consumption
4. Review the CI pipeline to ensure publishes only happen on tagged releases from main

Context

This is a shared infrastructure concern that affects all 14 npm maintainers. The goal is to prevent further storage growth and reduce the risk of npm taking action against the package.

cc @jeswr @timea-solid

[ewingson]

now that's what I call anticipating, Melvin !
heads up !

[jeswr]

Thanks for catching.

All SolidOS packages (e.g. solid-panes) face the same challenge and require a similar fix.

1. Should not be required if (4) is implemented.
2. 👍, could you update the CI on all SolidOS packages to do this?
3. This can only be done via CLI. Could you produce a script to unrelease all packages with 0 downloads from all SolidOS npm repos - I can run this once (2)+(4) are implemented if @timea-solid is unable to.
4. 👍, further I would encourage semantic commits and releases to be adopted. Could you implement this across all repos at the same time as (2).

[timea-solid]

I think I speak for the team when I say, we are fully on board with option 3.

Let me explain how development is currently in SolidOS before further action.

We have 13 repositories, which depend on each other. Disregarding rdflib, we have a few basic ones, to which we add all the pane repos:

For local development you need to use SolidOS repo which uses workspaces and lerna to link repos together. This does not work consistently when in watch mode, and not all repos have watch capabilities as of now. So there is a limit to local development.
What we do instead is, work local on a pane as much as possible. As soon as a local pane needs changes in say, solid-ui, we create a PR on solid-ui -> CI deploys on npm a PR version. This version we package in the local pane. Then one can work locally again for some time. One can build a mashlib version locally but as soon as one wants to chnage something again and see the entire mashlib, well... that's when it is again difficult.

[bourgeoa]

Like @timea-solid explains there are some architecture constraints to consider

• the 590 + version is not only on mashlib
• 13 packages links together to integrate to test a new mashlib. For this we need some test versions. We are beginning to work on this removing hash versions on test integration. Removing publishing full stack when not needed
• npm do not allow removing unused versions older than 72 hours if the repository as more than one owner/maintainer https://docs.npmjs.com/policies/unpublish#packages-published-more-than-72-hours-ago
• use of Github packages has not this constraint but imply to use packages in an organisation way @solidos/
  With Github packages it need also to be seen how it works with npm and CDN's

Investigating the above will take some time and resource if we don't want to break community work and reactivity.
This is not full time work.

point 1 : should not needed
point 2 : local artefacts are already used and not enough. Github packages constraints to be investigated
point 3 : to my understanding not allowed by after 72 hours for multi owner/maintainer packages
point 4 : depends of above and npm/Github packages integration

SolidOS is an under staffed project. Publish dev/production workflow is not a new issue.
I would like to see a dev/prod proposal we can discuss.

I am working on a test release orchestrator that only publish needed packages see issue SolidOS/solidos#253

[bourgeoa]

@melvincarvalho can you document any limitation on npm to the number of version a package might have. I did not find anything in the documentation.

[bourgeoa]

proposed fix SolidOS/solidos#259
Implemented in rdflib

[melvincarvalho]

Since the proposed fix (#259), there have been 15 more publishes this week alone including 2.1.5-test.0 through test.3 and several commit-hash prereleases. Each is ~20 MB and permanent. Is the fix working as intended?

For testing, file: dependencies would avoid publishing test versions to the public registry.