undefined | Better HN

0 pointsnemothekid10y ago0 comments

I don't see how this npm's problem - the language itself doesn't let you catch this problem - and the pattern itself is dangerous. I'd have to agree with IsaacSchlueter here.

If I have a library (libA) that uses fooV1 and another (libB) that uses fooV2, there is no reason I should expect those two dependencies to interop with each other (except explicitly stated by the developer).

The solution (that there should be one set of dependencies) is an even worse problem that currently afflicts the Golang community, which they have decided to solve the same way npm has decided to solve it - vendoring.

Now with Golang, if you only have 1 set of dependancies, and one of your libraries depended on an older version - your program just won't compile (unless you update the library to use fooV2) and I'm not sure how thats useful to anyone. Most people will just tell you should have have just versioned that dependency.

0 comments

spion10y ago

In the vast majority of cases, its not. But in the cases when people want to invent new globally useful abstractions, like bignum, promises, cleaner streams etc - i.e. to reshape the platform - they can't do that. For example, the overhead of adding bluebird as a dependency to every module quickly adds up, and bluebird had to fight with many issues stemming from multiple versions of it communicating with each other.

IMO while this has contributed to the growth of node the ecosystem, it also stifled the growth of node the platform.

j / k navigate · click thread line to collapse

0 pointsnemothekid10y ago0 comments

I don't see how this npm's problem - the language itself doesn't let you catch this problem - and the pattern itself is dangerous. I'd have to agree with IsaacSchlueter here.

0 comments

spion10y ago

IMO while this has contributed to the growth of node the ecosystem, it also stifled the growth of node the platform.

j / k navigate · click thread line to collapse