[scriby]

I used to use a project called now on npm that was abandoned a few years ago (https://github.com/Flotype/now). I was curious how this new project was using the same name on npm as the previous now that I had used.

Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package name transfers during the leftpad debacle, but there's just something weird about reusing package names for totally different projects...

[cphoover]

> but there's just something weird about reusing package names for totally different projects...

Not only is it weird but it is inherently insecure.

Even NPM's solution:

> "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support."

seems susceptible to social engineering. All it takes is for one heavily depended upon package to become compromised by a malicious actor, and the entire dependency graph is poisoned.

I'm not sure of a great solution, but it really makes you question the soundness of the NPM ecosystem.

[viperscape]

I really see no good reason not to employ namespacing with immutable packages. If a package is dropped, all is well still. If readoption is needed, people can use the new package, similarly named. It obviously also allows for similar but different named packages to exist, which I don't see as a problem. I can usually find the top repo on github for instance, even with multiple forks. I worry about Rust since they have decided against namespacing, even though some suggested otherwise, early on..

[brian_c]

I've had one of my package names transferred away from me with no warning, presumably after some period of inactivity. Npm as a repository seems to have gone totally insane, and I don't think I'll be publishing there anymore. I'll recommend people install my modules from a tag in the repo.

[snlacks]

I hope they break the API and create proper namespacing. I recommend using the model from Composer/Packagist.

[m1sta_]

Needs more hashes

[simula67]

There should be at least some warning on the page that an earlier project with similar name was replaced with this package.

People make fun of Java's namespace conventions [1], but it goes to show the advantages of not having to have a central authority to decide on these matters.

https://docs.oracle.com/javase/tutorial/java/package/namingp...