3 ms·

Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - n

• msbarnett 11y ago
  > Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - no matter how big the packages are - a huge problem. This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong. Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs? Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
• jldugger 11y ago
  > The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.