NPM silently suspends package adoption | Hacker News Reader

NPM silently suspends package adoption

twitter.com

77 pointsAloha36 comments

  If a package transfer does need to occur, then the only method to do so should be the owner doing it. The registry itself shouldn't have the ability.

This might be fighting fire with napalm. Namesquatting is very much a thing, and if every new package registry finds itself with millions of common names registered on day 1 those registries are going to become a lot less useful. This is also going to encourage a lot of bottom feeders to get money just to go away.

Package registries should instead consider all parties' (including greedy and unscrupulous third parties) motives, and try to come up with some scheme to make sure this process works.

Shallow, unqualified naming is part of the issue here. Look up, for instance, anything with the "Oracle" name. Not that I care for the company, but it makes no sense that oracle and oracledb are taken by 3rd parties. What would make more sense is to permit qualified names associated with an organization or user name. Jtsummers/oracledb would at least not be (easily) confused with an official Oracle product. It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names.

Having a single level for naming is just asking for trouble. Between valid name collisions and invalid name squatting, it becomes a much harder problem than necessary.

You'd think this would be common sense (Java solved this problem 25 years ago) but apparently some people are extremely opposed to non-flat package namespaces.

See e.g. Rust, where the idea of hierarchical crate namespaces has been politely but firmly shot down every time it's been requested.

This is only a problem now that npm has millions and millions of packages, IMHO having a flat structure helps in the beginning (abc/jquery vs def/jquery, which one is the official one?) and having a hierarchical structure helps later on.

com/jquery.

Java 99% solved this decades ago.

On Java it'd be the com.jquery/jquery. As opposed to io.github.randomperson/jquery.

Not before it became big. Usually projects start out under some random person GitHub page, and only register domain names later on when it gets traction.

True that, and I've seen packages switch group ids at this point, usually at a major version release.

But still makes it easier to verify that you're installing the package you intended.

And makes it very hard to deliver typo vulns or squat the "good" names.

And that's fine. A 1.0 release existing as both randomiser/jQuery and jQuery/jQuery is fine, and then 2.0 only exists as jQuery/jQuery; so long as your package manager has good tooling for rewriting imports (and usually sed is enough). Making migration to alternative implementations easy should already be a design goal.

The official one of course should be jquery/jquery. Or do it line docker does, and have a reserved official namespace that needs to be whitelisted (that of course has the downside that the people behind the projects don't have direct access and tends to end up with out-of-date packages).

Java took an approach with one set of trade-offs. Each approach has its pros and cons.

> It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names.

I do think Rust will get some form of namespaces, but it'll be quite a bit less powerful than what most proponents of namespaces want. There's been a bit of a disagreement (IIRC) about what a namespace signifies (would signify) in the Rust ecosystem.

Edit: I will say, it has been quite the contentious and has been re-hashed ad-naseum. For anyone interested in reliving arguments, search for "namespace" on https://internals.rust-lang.org - There will be a good half-dozen results to read through, though there is a fair bit of re-hashing and talking past each other.

Yeah, that makes sense. Basically namespacing on some unique identifier, such as a username/org name. That would alleviate a lot of package squatting concerns.

Java uses domains. Works great. To use the namespace prefix com.google.XXX you need to control google.com.

https://central.sonatype.org/publish/requirements/coordinate...

Wouldn't that move the squatting problem to the unique namespace identifier...?

With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`.

And if you say just use GitHub user names, you're merely relying on GitHub's support staff to sort it out for you (they're not magic, they have the same problem).

> And if you say just use GitHub user names

use domains? like java does for over 20 years?

This is one of the things that makes me think Deno will ultimately win:

  Deno Goals: Simplify the module system
  - No attempt at compatibility with existing Node modules.
  - Imports are relative or absolute URLs ONLY. (See Semantic Versioning)
  - Imports must provide an extension.
  - Remote URLs are fetched and cached indefinitely on the first load. Only if the --reload flag is provided will the resource be fetched again.
  - Vendoring can be done by specifying a non-default cache dir.

https://tinyclouds.org/jsconf2018.pdf

It has worked terribly, software often live longer than organizations or can easily change hands. And then we get the absurd directory structures, where half the code lives in com/oldcompanyname and half in com/newcompanyname and related code can be far away.

Even Sun went away and left nothing but a bunch of legacy package names.

> With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`.

The same way that Java packaging is nothing but a big fight over who owns "com.*"?

dot-com domain squatting is the OG name squatting. Everything under dot-com is taken. Even for new TLD names there is a bidding process.

Domains are not that great for project identifiers. Domain ownership is not permanent, but project identifiers should be.

> Domains are not that great for project identifiers.

I tend to agree. But the fact remains that you don't see fights over namespacing in Java even though everyone uses the same top-level space. I can't see how the claim "you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`" holds any water.

> Domain ownership is not permanent, but project identifiers should be.

Package names aren't actually linked to domain ownership. There's nothing stopping me from releasing software under com.oracle.

> It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names.

So we're back to fighting who owns "com.oracle"?

It seems like no matter the approach taken to validating namespace ownership there's some drawback.

No. There is no fighting over who owns com.oracle. There's nothing stopping you from releasing software in the com.oracle namespace, but when you do, either you are Oracle or you are falsely claiming to be Oracle.

Avoiding accidental collisions just isn't the same problem as validating a potentially fraudulent claim of identity. Namespacing solves the first problem; it's not intended to address the second, and doesn't.

IIRC, Microsoft apps can use a UUID. Which seems clever and future proof, so long its v4.

It's usually clearer who has the right to a given name though. For example, in a flat namespace any dozen competing AWS clients can claim `aws`, while in a two-level hierarchy its clear that that namespace belongs to Amazon.

..unless one of the dozen competing AWS clients claims that namespace first?

I think (verified) domains are the way to go, with some small whitelist of 'identity providers', so you could use say com.github.ojford, verifying it by logging in with GitHub OAuth rather than DNS record.

Why not go the BattleNet route and just allow any name collision but appending something unique to every instance of the name? In BattleNet's case it was a number, but with dependencies it might make more sense to add random words to avoid confusion. So there could be a "foo#cat" and a "foo#dog", and those names can remain unchanged forever. Or maybe go for alphanumeric IDs, though I think those would be much harder to tell apart.

I agree. A good place to start might be requiring email verification to publish a package so that the registry is more likely to have valid email addresses for maintainers.

Is this really an issue?

Who cares if they have to install oracle or @oracle/client?

I am very interested in the topic; I've gotten few common names over the years this way: "server", "@server", "translate", "files", "swear", "react-test", etc. In the vast majority of cases, I instead contacted first the previous maintainer, and in all cases (except one IIRC) they agreed they had basically abandoned the package and readily agreed to transfer them. A couple of them had some extra soft conditions like technical opinions, but these were fairly decent so I followed them.

I went ahead and wrote a whole article on the topic, including my tips to identifying what kind of packages were ideal for a polite request, which is always preferred to a hostile takeover like in this twitter thread IMHO:

https://francisco.io/blog/getting-a-great-npm-name/

I'm sad to see npm giving up on these, because in the 10+ years it has existed there is definitely space for squatting and greatly named abandoned packages.

Now I'm curious to know what technical opinions one could have after giving up a name. Mentioning the change in the readme? Releasing a new major version?

This has been said time and time again but packages should be namespaced. This problem was effectively solved decades ago by Java, and probably even further back than that.

I seriously wonder what goes on at npm. They seem very active in achieving absolutely nothing.

I'm afraid this is yet another case demonstrating in the end package management is hard and just reimplementing the easy parts like most language specific package managers do and pretending the rest is not needed, is not enough.

Why is NPM so consistently awful? It seems like there's a new scandal every year, whether it's packages getting hijacked, packages getting broken, fundamental parts of the system not working...

If I trawl through my own comments I can find several discussions of similar mishaps and problems.

Package management is hard, but you don't hear about pacman or pypi or RubyGems or NuGet having these kinds of problems. What gives?

This is a shame. I used that process quite a few times to pick up abandoned package and organization names. NPM really needs a plan to mitigate zombie packages if we can no longer petition for them.

I can't tell from this Twitter thread lacking nuance if there was a support rep screwup, if the package owner had bad contact info on the package, or what exactly happened.

Indeed it feels like this could be somewhat resolved by:

    - having npm contact the user
    - placing the package in a no-owner (and deprecated) state for a while

From the instructions it seems that you can just contact npm and say "I emailed the owner 3 months ago, got no answer" and have it within a few hours.

I'm also sad to see this process go because I used it at least once before.

Reply on news.ycombinator.com