3 ms·

I really don’t like one bit the design of npm. Projects should specify their dependencies not packages. For example if one of my dependencies uses leftPad in my

I really don’t like one bit the design of npm. Projects should specify their dependencies not packages. For example if one of my dependencies uses leftPad in my project I should have to specify leftPad as a dependency. This would encourage much better behaviour with dependencies because the costs would be crystal clear if it has 50000 dependencies you’d probably avoid installing it. It would also discourage lots of very small packages or you might even choose to add a version of leftPad to your codebase rather than let someone else be in charge of what is in it. Maybe the ship has sailed on JS/TS now but it would also discourage needless package churn.

capableweb 4y ago
What problem does this try to solve? That a lot of packages are being downloaded? You could already do what you're describing today, but odds are, you don't, because you value your time more than you value "having small amount of packages" for whatever reason.
- bombolo 4y ago
  Small amount of packages might very well lead to curated and well maintained libraries that do many things (as opposed to having 1 library per string function).
- andy_ppp 4y ago
  I’m just saying building a system that encourages/hides dependencies leads to bad software engineering in my opinion. Elixir does it the way I’ve outlined and I think that’s one of the many decisions they got right.
Joeri 4y ago
Under the npm model you are trusting the authors of your direct dependencies with judicious choice of transitive dependencies, and then those authors in turn trust the authors of their dependencies. In essence npm is a system that relies on a web of trust. A system like that cannot give any modicum of control, because typically a real world project will involve hundreds of package publishers, any one of which can break that trust with a poisoned patch version of a transitive dependency (or can be hacked), and it is effectively impossible to review all those dependencies every time they do a patch version bump. So developing with npm is always an act of faith that everyone will do the right thing. The remarkable part is how rarely it breaks down.
- dgb23 4y ago
  It’s really only a web of trust in a very naive sense. Most JS OSS is MIT licensed. There are no guarantees. It’s on _you_ to ensure the software works. Secondly people don’t really “trust” packages. They trust the usage, weekly downloads and quality of docs. They just assume this implies that it’s going to be OK, or that when deps break it’s nobody’s fault. Shit happens.
deleted 4y ago
[deleted]

capableweb 4y ago

What problem does this try to solve? That a lot of packages are being downloaded? You could already do what you're describing today, but odds are, you don't, because you value your time more than you value "having small amount of packages" for whatever reason.

bombolo 4y ago
Small amount of packages might very well lead to curated and well maintained libraries that do many things (as opposed to having 1 library per string function).
andy_ppp 4y ago
I’m just saying building a system that encourages/hides dependencies leads to bad software engineering in my opinion. Elixir does it the way I’ve outlined and I think that’s one of the many decisions they got right.

Joeri 4y ago

Under the npm model you are trusting the authors of your direct dependencies with judicious choice of transitive dependencies, and then those authors in turn trust the authors of their dependencies. In essence npm is a system that relies on a web of trust. A system like that cannot give any modicum of control, because typically a real world project will involve hundreds of package publishers, any one of which can break that trust with a poisoned patch version of a transitive dependency (or can be hacked), and it is effectively impossible to review all those dependencies every time they do a patch version bump. So developing with npm is always an act of faith that everyone will do the right thing. The remarkable part is how rarely it breaks down.

dgb23 4y ago
It’s really only a web of trust in a very naive sense. Most JS OSS is MIT licensed. There are no guarantees. It’s on _you_ to ensure the software works. Secondly people don’t really “trust” packages. They trust the usage, weekly downloads and quality of docs. They just assume this implies that it’s going to be OK, or that when deps break it’s nobody’s fault. Shit happens.

deleted 4y ago

[deleted]