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.
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.)
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.
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-...
And by date of project creation you can assume that others are parodies too: "LeftPad - Why should Node.js have all the fun?"
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.
- 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?)
Perfect in that it was fixed over a year ago?
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.
And yes, Yarn is the sane option for package management for Node. Why isn't it the default one yet?
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?
Great, then you should be able to mention at least one solid normal usecase as an example. I don't think there is one.
NPM has issues but most criticism of it is really complaints about bad dev practices (like not pinning versions correctly).
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.
https://github.com/npm/npm/issues/9633
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).
Again, bad dev practice.