Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience.
If npm packages used a Github-style "author/package" format, name collision would never be an issue again.
If npm packages used a Github-style "author/package" format, name collision would never be an issue again.
(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.)
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)
Not a problem at all. They will just get the name by force. It already happened before, google "npm kik".
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.
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.
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.
The problem is a package URI being reused without me realizing, and that problem would be solved.
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 don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.
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).
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.
e.g. philipwhiuk/gnome moves to gnome/core and there's a version published to philipwhiuk/gnome that pulls in gnome/core
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.
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.