[tzs]

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build.

Anyone know why they did it that way instead of giving each developer a subspace of the namespace that only that developer can publish under?

I'm thinking of the way it works on Java, where my package would be net.tzs.order_pizza, or GitHub (and numerous others) where it would be tzs/order_pizza.

[always_good]

I think it's annoying but also toxic to an ecosystem. You have to name your packages the same way you look for a domain name, people can squat on names, and it causes drama like how the 'kik' package was stolen from a developer and given to a company who never used it.

Nobody would've cared it the package was "tzs/kik". For example, the Elm package system does this right.

Another example of this failure is the Reddit subreddit system where a subreddit like /r/bitcoin makes it seem like the authority when it's a carefully moderated and biased subreddit. And nobody can really compete with it without getting a worse subreddit name like truebitcoin and bitcoin2 or something. Would be much more clear if it was /r/@theymos/bitcoin and /r/@spez/politics.

[MikkoFinell]

The failure is yours alone if you actually consider Reddit an authority on anything.

[MikkoFinell]

Downvoters: I of course meant an authority on anything ELSE than memes and karmawhoring. Sorry for not being clear about that.

[always_good]

Okay.

And you might say the failure is yours alone when you overeat, yet 30%+ of the USA is overweight. This little platitude only makes you feel better about yourself but isn't a good basis for designing something.

[MikkoFinell]

That's interesting. Unless I'm being forcefed, then who else is to blame? I have free will after all.

[mncharity]

> Anyone know why they did it that way instead of

Root causes wise, my impression is that software language engineering has a knowledge integration and communication problem. Lambda the Ultimate doesn't have a wiki. :) Academic papers provide a foundation, but a lot of practical professional knowledge is scattered, siloed in language communities, and time-consuming to access. Gathering best practices for language design and implementation isn't something we do well. So language creation projects often look like team and/or community "learn by doing" education exercises. Even with good people at leading companies... I had a conversation at redacted once, "why did you make (disappointing) design decision X?", "mumble mumble", "<facepalm> that's a (widespread) misconception, a misinterpretation of paper P (which admittedly could have been clearer), that's been kicking around for several decades now".

My fuzzy impression is the npm repo was not originally a mission focus, but rather a "don't be python" add on goal. Absent organized best practices, low-priority design decisions are often not made well. Perhaps Ruby, Perl5, and/or Python were copied, without attending to those communities experiences, and the implications for an even more fine-grained code sharing community.

[toomanybeersies]

This person on reddit apparently suggested it back in 2013: https://www.reddit.com/r/webdev/comments/7oljbe/xpost_rjavas...

Relevant excerpt:

> I proposed required namespaces (@user/package) as a requirement in 2013 and the npm developers acted like I had 2 heads.

[Jare]

In theory, deleted packages can't be taken over, their name remains reserved unless the company assigns it manually via some administrative process. That is, unless there are bugs which can actually delete packages, which seems to be the case here.

Namespaced packages/repos have their own problems (figuring out which is the "good" one after some time and a few forks happen)

[krapp]

>Namespaced packages/repos have their own problems (figuring out which is the "good" one after some time and a few forks happen)

Most if not all of these packages are hosted somewhere like Github. It's not hard to tell which repo has the most stars, fewest issues or most recent commit, that work's already done for you.

But, we're talking about Node packages here - many of which seem to be trivial, or single line functions. How many forks of left-pad could one expect to find?

[Jare]

> How many forks of left-pad could one expect to find?

Javascript github repos: 70 of left-pad and 29 of leftpad. Some are jokes, but still...

If you try the C++ package manager conan.io you will likely run into similar troubles. See for example https://github.com/lasote/conan-zlib/issues/23

[krapp]

Fair enough... that's a lot more than I would have expected. But I still think on balance there are more benefits to using namespaces than drawbacks. Without namespaces, the same problems of quality control exist, but the decisions are being hidden from you or made on your behalf by a central authority, or you're just stuck with whomever got to the name first.

[kaikai]

Organizations on npm can publish "namespaced" modules, that look like `@orgName/moduleName`. It's just optional.

[stevekemp]

That is a new facility.

[kaikai]

This npm blogpost about them was published almost three years ago: http://blog.npmjs.org/post/116936804365/solving-npms-hard-pr...

[krainboltgreene]

> and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build.

Nope.

[u801e]

What if the project that requires order_pizza has no restriction on what version it pulls in?

[krainboltgreene]

  - It still wouldn't be silent or automatic
  - npm-based projects have a package lock