When your code deployment model is effectively "download stuff from random websites", I feel like namespace recycling is the least of your worries.
(That is to say, trusting that any given named package that `npm install` downloads is what you think it is is really no different that trusting `wget https://example.com/thecode.tgz`. Even if you verify that the domain hasn't switched hands, you have no guarantee that the author's pipeline wasn't compromised, or that the author didn't add malware themselves. There's a reason Debian, Red Hat et. al. put a lot of effort into ensuring integrity of their repositories.)
>If npm packages used a Github-style "author/package" format, name collision would never be an issue again.
They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version)
But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians)
It does fix the problem, although consumers of the package need to first verify they trust the original author.
For example, if Google published "Google/polymer", dependents would be unaffected if a new package was published from "badguy/polymer". I think you're saying it's still not fixed because someone could register the Google author name before the real Google gets it, but that is a understood problem across every website.
>But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians)
The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner.
No one should be able to "take" google/ since the actual Google already owns github.com/google.
I'm suggesting NPM integrate Github's authentication API into their publishing process, to validate that the author owns a namespace if NPM doesn't already do that (I don't know, I don't use NPM.) If Bitbucket allows the same, then that's OK. The point is to have authors control namespaces, and NPM control package names but only validate namespaces. If namespaces are just another string that NPM controls and that can be handed out, revoked or taken over like package names then using them doesn't solve the intended problem at all.
Since NPM uses a centralized registry, though, some limitations would have to be imposed, and allowing multiple sources would mean allowing for conflicts between github:google/package and bitbucket:google/package. Ideally, namespaces should be unique and canonical, and the simplest way to accomplish that is just to allow publishing to a single source.
Seems like they're only allowing name reuse in the case of spam packages. Not allowing name reuse in that case might result in lots of names being rendered permanently unusable by automated spambots.
Assuming no actual users are depending on packages which are literally just spam, I don't really see an issue with reusing the names of those packages.
I'd like to see a package registry with (1) Github-style author-namespaced packages, and (2) package signing (i.e. if an author starts signing packages with a different key, I'd like to know about it). Maybe integrate the latter with Keybase to help users decide if they should trust a key.
I don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.
Package signing by the author helps, but not if (a) the author's key is compromised, or (b) the author acts in bad faith. With npm-style package registries, the risk of such an event increases with the number of dependencies your project has.
Better to (a) ship your code with explicit version and content dependencies (e.g. a SHA-256 of the package you expect to exist), or (b) delegate trust in upstream packages to fewer, more well-vetted, authorities (i.e. distro-style).
(1) has the consequence that names are associated with the original creator long after they may no longer be involved.
Package signing I can't tell if it's a good idea or not. It would require you to accept a new key in this case, but that is going to happen super frequently with NPM, inducing alert fatigue, and it doesn't do anything to prevent the authors' publishing credentials getting stolen.
I'd also like a bunch of checks applied to my use of that registry.
1. only packages > nK downloads
2. only packages with tests
3. only packages with publicly available code that is same that I am downloading
4. only packages with > nnn stars, forks, issues, pull requests
All are just proxies for being a valid node in a dependency graph.
And like to know if any transitive dep violates my inclusion rules.
I think package URIs should include a secure hash of their contents.
Although you won't get updates without asking for them - I'm not sure that's a bad thing - you can be assured that you'll either get the package you were expecting or no package at all.
(That is to say, trusting that any given named package that `npm install` downloads is what you think it is is really no different that trusting `wget https://example.com/thecode.tgz`. Even if you verify that the domain hasn't switched hands, you have no guarantee that the author's pipeline wasn't compromised, or that the author didn't add malware themselves. There's a reason Debian, Red Hat et. al. put a lot of effort into ensuring integrity of their repositories.)