6 ms·

Ask HN: Why All the Hate for NPM?

• gus_massa 8y ago
  Remember "How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript" https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
  • gitgud 8y ago
    True, but it's now no longer possible to remove a package from npm, which kind of solves this module resolution problem. However a malicious actor could still upload a broken minor version that most node projects would try to automatically resolve to, and thus break...
    • dangerface 8y ago
      > which kind of solves this module resolution problem Your exception is not limited to malicious actors as even ligitmate packages like uglifyjs have had to do this. The NPM developers themselves have no problem deleting packages which would result in the same problems. They solved their problem by pushing it onto the rest of us.
  • muzani 8y ago
    The resolution of this also brings up why people dislike NPM. It's no longer about the whole open source thing anymore. What you put up there stays up there and isn't really yours anymore.
• xs83 8y ago
  I think a lot of it stems from the fact that many javascript developers blindly use packages for the most basic of things. The Left Pad mentioned above is a prime example - do you really need a dependency for that? Start adding nested dependencies and well it's simply a mess!
  • gitgud 8y ago
    The Left Pad incident was a huge wake up call for the community, but not for the reasons most people state (dependencies are bad! why not write it from scratch!). Rather, it shows that dependencies should really be immutable, at least versions of dependencies anyway. It seems it's no longer possible to remove a package from npm, you're only able to deprecate it. Which means Left Pad cannot happen again, in this way. Software reuse is an important part of progressing technology and I think it should be encouraged... or at least made easy...
    • stephenr 8y ago
      You think it’s logical to have an entire module to do foo % 2 === 0 ? What about another module to call the first one and invert the return? Development based around npm modules is a joke
      • gitgud 8y ago
        It's not logical, but it should be possible to do something trivial in a package. What's the alternative? Allow only packages with code over 100 lines? 1000 lines? Packages are an excellent way to share code, regardless of complexity...
        • krapp 8y ago
          >What's the alternative? Allow only packages with code over 100 lines? 1000 lines? The alternative is allowing packages with more than a single function. It's NPM and the javascript development culture which is enforcing the arbitrary limit of "no more than a single function per package." Sure, you can do trivial things in a package, but that calls into question the usefulness of enforcing that level of granularity versus having libraries of related functions, shallower dependency trees and less fragility.
• djhaskin987 8y ago
  Where to start. Probably the two biggest arguments are bloat[1] and broken builds. Both seem to be caused by an obsession with the culture of "never reinvent the wheel"[2] which can be stifling and over-the-top, especially given a community so willing to publish backwards incompatible changes come hell or high water. Both of these -- ease of publishing breaking versions and making libraries that are 11 lines long for the sake of not repeating them -- may have something to do with how npm manages dependencies. That is, it doesn't. You ask for a specific version of a library and you get it. Simple. You don't share this code version other libraries on the system. It sort of makes it easy to do the wrong thing, like backwards incompatible changes. For another example, this can cause problems when library B and A get results from calling library C and then communicate to each other using those results. You see, A uses C at a completely different version than B does. You end up with madness, and two copies of C (bloat). Contrast this with maven. Yea, lots of small libraries, but maven only allows one version of a library to exist and doesn't tell you exactly which one it will pick [4]. This is horribly broken BUT encourages people to NOT write backwards incompatible stuff. It encourages a healthy community. Maven central doesn't receive nearly as much hate as npm in my experience Then there's the crypto mining incident[3], but that could arguably have happened in one of several communities, really. [1]: https://twitter.com/tdvorak/status/678613940746756096?s=19 https://twitter.com/tdvorak/status/678613940746756096?s=19 [2]: https://xkcd.com/2140/ https://xkcd.com/2140/ [3]: https://link.medium.com/UVCo1GTaaW https://link.medium.com/UVCo1GTaaW [4]: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html https://maven.apache.org/guides/introduction/introduction-to...
  • gitgud 8y ago
    Well, broken builds are bad, but this can happen with any package management system right? Any open, easily updatable package management system will encounter these problems. Only testing and curation to ensure there's no broken builds will solve the broken builds issue. As for bloat, software reuse should be at least an option, a better phrase is "Reinvent the wheel, only when necessary". You're example of Maven is a much less flexible system, although it promotes stable API's. The main problem with only allowing one version of a dependency in a project is that dependencies aren't isolated per package, which means with lots of libraries there's no way to guarantee that they all have the exact correct version of the library they need, which will inevitably result in weird errors. The only reason libraries should use the exact same version is if they're communicating like you mentioned, soooo why not just explicitly state that dependency too then?
• quickthrower2 8y ago
  In defence of NPM it is Javascript that lacks a decent core library like you’d get with .Net or Java, you just get the very basics in the J.S. language (where as most languages have even less in the language but bundle a good class library). This means you need leftpad, moment, etc. stuff you don’t need in .net or Java.
• deleted 8y ago
  [deleted]
• dangerface 8y ago
  Most of the complaints I have heard are about the developers using their position of power to push their own political agenda. In the past they have ripped off some ones copyrighted code when it was a dependancy for everything[1]. After that they then deleted other peoples packages claming copyright infringement because there partner wanted the package name[2] A lot of people moved to the faster alternative yarn, this caused the NPM developers to rain in their bull. Their past actions and how they wield power are a demonstration that they should not have it, their attitude is one rule for us and another for everyone else. [1] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [2] https://kodfabrik.com/journal/i-ve-just-liberated-my-modules/ https://kodfabrik.com/journal/i-ve-just-liberated-my-modules...
  • gitgud 8y ago
    > Most of the complaints I have heard are about the developers using their position of power to push their own political agenda. If a developer is the authority on a package, they should be able to do what they want right? Not sure why this is a bad thing, people can fork the project if they don't agree with the changes. Or just use previous versions. What's the alternative? A single authoritarian political agenda? > A lot of people moved to the faster alternative yarn, this caused the NPM developers to rain in their bull. Yarn is just another CLI tool, it doesn't have its own packages and connects to the NPM repository. Also, it's now extremely hard to remove or change a version of a package on NPM...
    • dangerface 8y ago
      I was referring specifically to the developers of NPM and provided links to examples of them abusing their power. Yes creating a non authoritarian fork is the only effective alternative, which is why I mention yarn. Yarn might not solve all of the problems with NPM but it showed the NPM developers that people would build alternatives if NPM pushed them to it. In response NPM has lifted a lot of yarns features and improved its speed. Despite not being perfect it was at least affective enough as an alternative for NPM to notice and fear.
• iraldir 8y ago
  On top of what's been already mentioned, a lot of people are starting to not trust NPM because it is a for profit business, dependant on investor's money. It might not be here forever, it might be bought by some other actor etc. It's also a giant attack vector. Create a popular package or buy or get ownership from a developer of a package, and you can easily hide code in the mified deployed build while not having in the source code. Using complexe hiding methods, you can hide code in a subsubsub dependency of something that will, say, copy input fields and send them via XHR, every 100 times and not when debugger tools are open, or only when you detect you are in a country where the targeted developer is not located etc. Even worse for nodejs libraries.