[tshaddox]

> 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]

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]

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

[HideousKojima]

https://www.npmjs.com/package/is-odd

447,211 weekly downloads for what can be done in vanilla JS with foo % 2 === 1;

[oauea]

You can thank Jon Schlinkert for that: https://github.com/jonschlinkert?tab=repositories

He abandoned the projects, but:

* https://github.com/jonschlinkert/is-odd

* https://github.com/jonschlinkert/is-even

Of course that doesn't stop them from getting ~500k downloads/week.

[Ayesh]

Which itself depends on is-number package.

[zelphirkalt]

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]

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]

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.

[LadyCailin]

leftpad was a small amount of code too. If it’s a small amount of code that’s design stable and downloaded often, it’s an extremely strong candidate for inclusion in the standard library.