| 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?)