4 ms·

> That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to ha

> That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to have multiple versions of same dependency in the dependency tree -- often seen as a huge advantage over other platforms -- is in fact part of the problem. Aren't npm dependency trees so large because JavaScript doesn't have much of a standard library? And also, similarly, the community is so large and has been moving so fast that even de facto standards have difficulty forming and surviving at a large scale across the community.

handrous 5y ago
The lack of static typing (in base JS, at least) also makes it hard for tools to automatically spot very basic brokenness in dependencies without (repeatedly) running & testing the code. This makes even "safe" version bumps less trustworthy and harder to audit, and makes it harder for developers to notice if they've accidentally changed an interface on one of their libraries that they marked as a minor patch (i.e. the errors are both harder to check for, and more likely to occur, basically because they're harder to check for), so it's tempting to stick to old versions longer. Add to that everything else—the fast pace of changes, javascript "culture", the weak standard library, the tendency to patch in what ought to either be basic language features or else avoided in favor of more-vanilla idioms, often in competing and incompatible ways—and all that is how you end up with 20 slightly-different copies of the same damn library in your dependency tree, and then 20 other copies of another library that does the same thing.
zelphirkalt 5y ago
Big part of the insanity is also how projects introduce dependencies for very simple things like padding a number or a string.
- HideousKojima 5y ago
  https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd 447,211 weekly downloads for what can be done in vanilla JS with foo % 2 === 1;
  - Ayesh 5y ago
    Which itself depends on is-number package.
    - zelphirkalt 5y ago
      You and GP have shown me new even more scary depths here. Not sure whether I should thank you for that. (When does the next flight off this rock go?)
      - tshaddox 5y ago
        It's not really that crazy. This package is a small amount of code, but it's important code (the same goes for this package's dependency is-number). This package shows up in the dependency trees of some popular packages, which is probably where most of the weekly downloads come from. If you're writing straightforward application code where you already know you have a valid number, then this package probably isn't for you. You can just do num % 2 === 1.
        zelphirkalt 5y ago
        I get it, JS is a weird language, but simple things like "is number" are still easy enough to do in JS, especially, when ints and floats are all just "number" in JS: function is_number(val) { return typeof val === "number"; } With a function that easily written, no one should have any excuse to depend on a third-party dependency for it.
        tshaddox 5y ago
        But the code you posted is not what the code in this package does. If all you need is the code that you posted, then you should absolutely use that.
        kinjba11 5y ago
        > not what the code in this package does Here's `is-number` (https://github.com/jonschlinkert/is-number/blob/master/index.js https://github.com/jonschlinkert/is-number/blob/master/index...): module.exports = function(num) { if (typeof num === 'number') { return num - num === 0; } if (typeof num === 'string' && num.trim() !== '') { return Number.isFinite ? Number.isFinite(+num) : isFinite(+num); } return false; }; Care to explain why these 5 lines of code need to be a package? To me, having something so simple be a package by itself is absurd.

handrous 5y ago

The lack of static typing (in base JS, at least) also makes it hard for tools to automatically spot very basic brokenness in dependencies without (repeatedly) running & testing the code. This makes even "safe" version bumps less trustworthy and harder to audit, and makes it harder for developers to notice if they've accidentally changed an interface on one of their libraries that they marked as a minor patch (i.e. the errors are both harder to check for, and more likely to occur, basically because they're harder to check for), so it's tempting to stick to old versions longer. Add to that everything else—the fast pace of changes, javascript "culture", the weak standard library, the tendency to patch in what ought to either be basic language features or else avoided in favor of more-vanilla idioms, often in competing and incompatible ways—and all that is how you end up with 20 slightly-different copies of the same damn library in your dependency tree, and then 20 other copies of another library that does the same thing.

zelphirkalt 5y ago

Big part of the insanity is also how projects introduce dependencies for very simple things like padding a number or a string.

HideousKojima 5y ago
https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd 447,211 weekly downloads for what can be done in vanilla JS with foo % 2 === 1;
- Ayesh 5y ago
  Which itself depends on is-number package.
  - zelphirkalt 5y ago
    You and GP have shown me new even more scary depths here. Not sure whether I should thank you for that. (When does the next flight off this rock go?)
    - tshaddox 5y ago
      It's not really that crazy. This package is a small amount of code, but it's important code (the same goes for this package's dependency is-number). This package shows up in the dependency trees of some popular packages, which is probably where most of the weekly downloads come from. If you're writing straightforward application code where you already know you have a valid number, then this package probably isn't for you. You can just do num % 2 === 1.
      - zelphirkalt 5y ago
        I get it, JS is a weird language, but simple things like "is number" are still easy enough to do in JS, especially, when ints and floats are all just "number" in JS: function is_number(val) { return typeof val === "number"; } With a function that easily written, no one should have any excuse to depend on a third-party dependency for it.
        tshaddox 5y ago
        But the code you posted is not what the code in this package does. If all you need is the code that you posted, then you should absolutely use that.
        kinjba11 5y ago
        > not what the code in this package does Here's `is-number` (https://github.com/jonschlinkert/is-number/blob/master/index.js https://github.com/jonschlinkert/is-number/blob/master/index...): module.exports = function(num) { if (typeof num === 'number') { return num - num === 0; } if (typeof num === 'string' && num.trim() !== '') { return Number.isFinite ? Number.isFinite(+num) : isFinite(+num); } return false; }; Care to explain why these 5 lines of code need to be a package? To me, having something so simple be a package by itself is absurd.