This is risky to say but... NPM is a bad package manager. I could blab about why forever but tons of other people already have. I've never used a popular language with a package manager as bad as npm.
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.)
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:
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.
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?
> 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?
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.
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.
- 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?)
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.
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.
One other one is that it has hilariously poor performance, and bizarre failure cases. For some forms of network failures it'll just say "callback called too many times" and crash.
There are literally no worse major package managers.
A good package manager can be misused and still work reasonably well; a bad one doesn't even work all that well when used correctly.
I especially like the part where it says "This is most likely not a problem with npm itself", even though it clearly is a problem with npm itself (as evidenced by non-deterministic nature of the bug).