An example alternative is a ports tree. You have a repository which can build packages from descriptions. This repository itself is a formal parameter, so it can be replaced easily. It's also a basic filesystem structure that doesn't depend on external services directly in order to be queried. At this point in history, we are starting to become much more capable of federating basic read-only filesystems, so the availability of a simple ports tree (and any referent tarballs) are no longer depending as much on central authority servers.

In addition to the BSDs, this is how the Nix ecosystem manages its package repositories. There is (of course [0]) a singularly large repository, nixpkgs, but there are also forks which can vary greatly in appearance, from nixpkgs + custom packages, all the way to systems like Triton, which replace a lot of the fundamental repository structure. Nonetheless, they are largely interchangeable at the top level.

NPM would have to be distributed as a git repository, at the least, for this to be feasible.

[0] Why is there always a single large structure at the center of repositories of data? It's because data likes to aggregate as a side-effect of what some people call "network effects" or "economies of scale" or "Boyle's law", although I'm not sure that any of them cover it succinctly. The best introduction to this that I know of is the two-balloon experiment: https://en.wikipedia.org/wiki/Two-balloon_experiment

Separate uncoordinated repositories (which risks namespace collisions), or separate repositories with a rule effectively providing a system for assuring universally unique names, e.g., by prefixing project names with the identification of the repository responsible for the local uniqueness of the name.

The alternative is many.

E.g. apt.