6 ms·

So what does NPM do differently than plugin managers from other languages? I can't name one where the dependency hell is this big.

leetrout 6y ago
My personal take having “grown up” with all of this - JS is one of the worst ecosystems for relying on external packages for everything. It’s more the culture than the tooling. One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.
- smitty1e 6y ago
  Inviting the question of why the culture hasn't sprouted a "package rationalizer" to produce a curated, tested, noise-filtered distribution of useful functionality. Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.
  - ng12 6y ago
    Because we can't even agree on whether React or Vue or Angular is best. In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.
- pixelrevision 6y ago
  Go in particular has an amazing standard library and very clear guidelines on how to write code. JavaScript does not have either of those things so it promotes people releasing competing libraries with similar functionality written in various different styles.
- erik_seaberg 6y ago
  Copying code is pinning a dependency, committing to never update it, and hiding the evidence.
  - leetrout 6y ago
    Perhaps.
  - lioeters 6y ago
    That's not always true. Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever). Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first. Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.
    - erik_seaberg 6y ago
      I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.
      - lioeters 6y ago
        > explicitly depending on our fork of their library would be clearer and safer. I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.
deleted 6y ago
[deleted]
thomasfoster96 6y ago
I’d say compared to other languages there’s been two big issues: 1. A not insignificant number of packages are either polyfilling things in browsers, or providing a consistent (or ‘isomorphic') API for certain things across both browsers and Node.js, or adding things that should have been in a standard library. 2. A lot of packages still seem to be distributed primarily as CommonJS and not ES Modules. CommonJS makes tree-shaking harder than it should, so it was often just easier to break what should have been a single library into many smaller pieces. Hopefully in the not too distant future library maintainers get around to reading the Node.js docs[0] fix some of this. [0] https://nodejs.org/api/esm.html https://nodejs.org/api/esm.html
fxtentacle 6y ago
It's the users. And money. JavaScript is super popular and used by companies so there are lots of people releasing their own open source project in an attempt to hustle into a well-paid job by looking more experienced than they really are. I'd say it's the same reason why there are so many bad Java and Php tutorials. C++ for comparison is shielded from this because it's not the kind of programming language that you would learn in a weekend seminar to improve your salary.
deleted 6y ago
[deleted]
tasogare 6y ago
Other languages have for most part a good standard library. In C# for instance you can make a small/medium project with only a few third party libraries because the base class libraries (BCL) contains lot of data structures and classes used for common use case (encryption, unicode, file operations, etc.)

leetrout 6y ago

My personal take having “grown up” with all of this - JS is one of the worst ecosystems for relying on external packages for everything. It’s more the culture than the tooling. One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.

smitty1e 6y ago
Inviting the question of why the culture hasn't sprouted a "package rationalizer" to produce a curated, tested, noise-filtered distribution of useful functionality. Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.
- ng12 6y ago
  Because we can't even agree on whether React or Vue or Angular is best. In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.
pixelrevision 6y ago
Go in particular has an amazing standard library and very clear guidelines on how to write code. JavaScript does not have either of those things so it promotes people releasing competing libraries with similar functionality written in various different styles.
erik_seaberg 6y ago
Copying code is pinning a dependency, committing to never update it, and hiding the evidence.
- leetrout 6y ago
  Perhaps.
- lioeters 6y ago
  That's not always true. Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever). Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first. Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.
  - erik_seaberg 6y ago
    I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.
    - lioeters 6y ago
      > explicitly depending on our fork of their library would be clearer and safer. I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.

deleted 6y ago

[deleted]

thomasfoster96 6y ago

I’d say compared to other languages there’s been two big issues: 1. A not insignificant number of packages are either polyfilling things in browsers, or providing a consistent (or ‘isomorphic') API for certain things across both browsers and Node.js, or adding things that should have been in a standard library. 2. A lot of packages still seem to be distributed primarily as CommonJS and not ES Modules. CommonJS makes tree-shaking harder than it should, so it was often just easier to break what should have been a single library into many smaller pieces. Hopefully in the not too distant future library maintainers get around to reading the Node.js docs[0] fix some of this. [0] https://nodejs.org/api/esm.html https://nodejs.org/api/esm.html

fxtentacle 6y ago

It's the users. And money. JavaScript is super popular and used by companies so there are lots of people releasing their own open source project in an attempt to hustle into a well-paid job by looking more experienced than they really are. I'd say it's the same reason why there are so many bad Java and Php tutorials. C++ for comparison is shielded from this because it's not the kind of programming language that you would learn in a weekend seminar to improve your salary.

deleted 6y ago

[deleted]

tasogare 6y ago

Other languages have for most part a good standard library. In C# for instance you can make a small/medium project with only a few third party libraries because the base class libraries (BCL) contains lot of data structures and classes used for common use case (encryption, unicode, file operations, etc.)