[sillysaurus3]

It's not risky to say. It's risky to do a shallow critique with no solid analysis. I would personally enjoy hearing a critique of why npm is bad in comparison to other package managers.

As someone who has spent a lot of time with npm (not even as a webdev), it appears to solve all of my common use cases while also dealing impressively well with various versions of specific dependencies. (Like, A depends on B@0.0.1, C depends on B@0.0.2, etc.)

[int_19h]

One of the basic features expected of a package manager is reproducibility (i.e. if two people build the same code with the same dependencies, it should produce the same result). On that count, npm is literally broken by design:

https://github.com/npm/npm/issues/10999

[allover]

Well no, installing 2 packages, one after the other from the command-line (as in that issue) is not the way you 'share builds' with npm. You do that via a package.json + 'npm shrinkwrap' "lockfile".

Shrinkwrap does have known issues (mainly w.r.t. platform-specific modules and verbosity), though I've never had any problems with it, but if you want a better lockfile I suggest the Yarn client.

(Believe Python's pip behaves similarly to npm in that issue).

I prefer Yarn's lockfile handling, but saying npm is 'broken by design' is wrong.

[int_19h]

There are evident security issues with this, as spelled out in the bug. Yeah, I'd consider that broken. Of course the repro is contrived, but it's not at all unusual to install some packages manually. The point is that once you do so, you might not get the same result later from package.json, either.

And yes, Yarn is the sane option for package management for Node. Why isn't it the default one yet?

[Can_Not]

> but it's not at all unusual to install some packages manually

If you're taking about deployments, that's definitely unusual. Outside of deployments, what's a scenario where deterministic builds are important, but it would be considered normal to manually install them anyways?

[int_19h]

I don't see why deterministic builds would only be important for deployments. Even ignoring the security issues here (which don't necessarily apply only to deployments), there's this whole classic "works for me, not a bug" situation.

[Can_Not]

> I don't see why deterministic builds would only be important for deployments.

Great, then you should be able to mention at least one solid normal usecase as an example. I don't think there is one.

[forgotpw1123]

There's a ton of annoying little stuff (like doing nothing to prevent path names too long for your filesystem) that could be forgiven for being young, but the big problems are in its architecture.

Node module syntax is non standard and can't be tree shaken, with a little more forethought it could have been designed to support static analysis and they wouldn't have needed to reinvent the module syntax for ES6. You can't reliably tell if a piece of code is using a given package until you run it.

The dependency resolution sucks. It's better now that they finally made it so nested dependencies aren't duplicated, but why the hell do I have to run a manual dedupe command to do so? What that tells me is that npm doesn't actually track dependencies, its hardly more than a fancy file downloading tool.

The repository curation sucks. I'm not sure if you've used Python's package manager, or Java's, or C#'s, or Perls, but npm has zero package curation and is filled to the brim with garbage compared to the others. I have published packages for C# and Java and the semantics are well defined and reasonable, you even cryptographcally sign your code and the system checks to make sure you upload documentation etc... In the case of java, which has the best system I've seen, they even use something similar to DNS validation to make sure you control package namespace.

The above point is the absolute worst thing about npm and drawfs the other problems. Let me give an example by pasting the package publishing guidelines for Maven(Java) vs npm:

Publishing an npm package: >Use npm publish to publish the package. >Note that everything in the directory will be included unless it is ignored by a local .gitignore or .npmignore file as described in npm-developers. >Also make sure there isn't already a package with the same name, owned by somebody else. >Test: Go to https://npmjs.com/package/<package>. You should see the information for your new package.

I had to condense the Java guidelines but it's roughly this: create JIRA account apply for access review requirements verify namespace ownership generate crypto keys package coordinates/versioning project description URL and license info developer info SCM info package deployment generate binaries revolve package dependencies crypto sign package generate documentation online verification

Sounds like a lot of work right? It takes a few hours to setup and verify your domain/keys the first time but after that all of these steps are automated. The signing/building/doc generation/ deployment is totally automated. Npm is a toy in comparison.

from their docs: Why Do We Have Requirements? In order to ensure a minimum level of quality of the components available in the Central Repository, we have established a number of requirements your deployment components have to meet. This allows your users to find all the relevant details about the components from the metadata provided in the Central Repository. The following sections will detail these requirements.

Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and CPAN would have never let something that stupid happen.

[nilliams]

Awfully vague/FUDdy criticisms there:

- dynamic require()'s can't be tree-shaken: same is true of other langs, e.g. Python. Perfectly understandable IMO as Node was designed for the server, in a time tree-shaking (largely desirable for front-end code) wasn't a priority. Also it is a standard (CommonJS).

- long pathnames is a Windows only issue and afaik fixed by npm 3's "flattening".

- npm is worse than Maven because 'npm publish' is too easy?

- you don't need to run dedupe.

- you say npm isn't curated but I'm not aware those other registries are curated either?

- 'left-pad is a perfect example of why npm sucks' ... except the ability to delete packages has been fixed, so should that be 'sucked'?

(Edit: how on earth do you format lists correctly on HN?)

[feduzi]

> Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and CPAN would have never let something that stupid happen.

O RLY?

* https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0

* https://www.nuget.org/packages/left-pad/

* https://pypi.python.org/pypi/left-pad/

* http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.p... (LeftPad - Why should Node.js have all the fun? - comments on the package)

-- UPDATE

About package removal...

* http://stackoverflow.com/questions/20403387/how-to-remove-a-...

[vincnetas]

At least first one is a parody: "This library is clojure/clojurescript port of left-pad, it's NOT recommand to use this library actually :)."

And by date of project creation you can assume that others are parodies too: "LeftPad - Why should Node.js have all the fun?"

[forgotpw1123]

All of those left-pad libraries are a jest, it's trivial to do padding in those languages. I was wrong about Python and removing packages but on Nuget and Maven you can't, its not allowed.

I think it's worth noting that with Java at least, besides not allowing package removal, the namespace is tied to a unique identifier with ownership verification, so the cause of the left-pad fiasco (kik wanting his namespace) is extremely unlikely to happen in the first place.

[oliverkyss]

If the curation process allows joke packages to pass through, it is completely useless. Looks like the only difference from npm is extra bureaucracy then.

[uitgewis]

I assume they're referring to the prior ability that NPM packages could be removed at will.

[Can_Not]

> Left-pad is a perfect example of why npm sucks.

Perfect in that it was fixed over a year ago?