[cxr]

I'm happy to criticize NPM the tool. The whole thing is designed as a second, crummier version control system that lives in disharmony with and on top of your base-level version control system (so it can subvert it). It's a terrible design.

There's basically at most one reasonable use for npm: as a glorified download manager, i.e. to quickly fetch a module by name (right before you check it in to version control with Git). This differs wildly, of course, from how it's actually used, which is as a drug that sweeps mountains of unaudited code under the rug so people can trick themselves and others into thinking that none of it's really there on the basis that it's not visible when anyone first clones the repo.

To answer the other commenter's question, "How should NPM prevent archaic dependencies": it shouldn't; it's okay for programmers to be responsible for their work.

[spankalee]

How is npm a version control system?

npm is a fairly standard package manager, much like many others, pretty good even.

I don't know of anyone who says that package managers and source control solve the same problems. They both happen to use the word and concept of "version" but to mean different things. Yes, some projects vendor in their dependencies into their source control system, but they must either manually verify package version compatibility or use a package manager like npm to help them do it. And vendoring doesn't work for actual packages published to the package repo. If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

[cxr]

> npm is a fairly standard package manager, much like many others

Yes.

> They both happen to use the word and concept of "version" but to mean different things.

Right. I think I covered that adequately.

> And vendoring doesn't work for actual packages published to the package repo.

What?

> If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

Yes. Alternatively:

Please clearly articulate the purpose of a package manager (in the sense of the term when it's used to describe npm and others). See if you can work it out so that you can state it in the form of a testable hypothesis (i.e. ideally in quantitative terms like MBs/GBs of disk space used, or network transit, or time to fetch—or anything that you think accurately reflects what you consider to be the value proposition that npm fulfills and which we can use to evaluate it in scenarios where it would or would not be a good fit).

[spankalee]

Man, this isn't hard.

The purpose of a packages manager is to allow me to describe the packages and versions that my own package depends on, and download compatible versions of those dependencies and their transitive dependencies in such a way that dependencies are shared and that my runtime can use them.

npm does that, as does Cargo, Pub, Gems, pip, etc.

[cxr]

> Man, this isn't hard.

Well, you ducked the question—and what you did say isn't particularly illuminating to anyone who is already familiar with npm and cargo—so it's not at all clear at this point that you're right about that. (Your overall comment actually reads a lot like the sort of thing that I mentioned at the top of this thread: "non-specific appeals to the necessity of it all [...] vague arguments [...] they manage to work in a slight that's designed to paint you, implicitly or explicitly, as a junior".)

I'll ask again: what is the value proposition of npm-like package managers in quantitative terms? Your hypothesis should be falsifiable, if not testable.

If you're having difficulty, we might start here:

> in such a way that dependencies are shared

Why?

[spankalee]

"Your hypothesis should be falsifiable, if not testable"

Seriously? There are not strange requirements, and you're ducking the issue by trying to force a pseudo-scientific dialog on this. There are language semantics in play, among many other considerations that I'm sure you're well aware of.

But I don't need to convince you, you're already convinced. Have fun.

[cxr]

> Seriously?

Yes, seriously.

> There are not strange requirements

Huh?

> you're ducking the issue

I am? How? (What is the issue I'm ducking?)

> There are language semantics in play, among many other considerations that I'm sure you're well aware of.

What?

> I don't need to convince you, you're already convinced.

I don't get it. (What am I already convinced of?) You said this wasn't hard. So why does it seem that way?