| ▲ | RVuRnvbM2e 3 days ago |
| Fucking this. I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix. No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't. |
|
| ▲ | zer00eyz 3 days ago | parent | next [-] |
| > It's an ecosystem and cultural problem that npm encourages huge dependency trees It is an ecosystem and culture that learned nothing from the debacle of left pad. And it is an affliction that many organizations face and it is only going to get worse with the advent of AI assisted coding (and it does not have to be). There simply arent enough adults in the room with the ability to tell the children (or VC's and business people) NO. And getting an "AI" to say no is next to impossible unless you're probing it on a "social issue". |
|
| ▲ | Yoric 3 days ago | parent | prev | next [-] |
| The thing is, having access to such dependencies is also a huge productivity boost. It's not by accident that every single language whose name isn't C or C++ has pretty much moved to this model (or had it way before npm, in the case of Perl or Haskell). The alternative is C++, where every project essentially starts by reinventing the wheel, which comes with its own set of vulnerabilities. I'm saying this without a clear idea of how to fix this very real problem. |
| |
| ▲ | fdsfdsfdsaasd 3 days ago | parent | next [-] | | It's more like capex vs opex. Some languages and frameworks - you have to maintain the same level of effort, just to keep your apps working. | |
| ▲ | fooker 3 days ago | parent | prev [-] | | > The alternative is C++, where every project essentially starts by reinventing the wheel Sure, in 1995. Most C++ projects nowadays belong to some fairly well understood domain and for every broad domain there is usually one or two large 'ecosystem' libraries that come batteries included. Huge monolithic dependency with well stablished governance instead of 1000 small ones. Examples of such ecosystems are Qt, LLVM, ROOT, tensorflow, etc. For smaller projects that want something slightly more than a standard library but not belonging to a clear ecosystem like the above you have boost, folly, abseil, etc. Most of these started by someone deciding to reinvent the wheel decades ago, but there's no real reason to do that in 2025. |
|
|
| ▲ | alehlopeh 3 days ago | parent | prev | next [-] |
| “It’s not difficult to fix, just change the entire culture” The difficulty comes in trying to change the entire culture. |
| |
| ▲ | aspenmayer 3 days ago | parent [-] | | “Doctor, it hurts when I do this!” “Stop doing that!” “But I wanna!” | | |
| ▲ | Jensson 3 days ago | parent [-] | | That is valid though, if someone says "It hurts when I walk" its not reasonable to tell them to not walk, you try to figure out why it hurts and if it can be fixed. Other languages has similar package managers as npm, but with much less issues, so it can be fixed without changing the package manager completely. | | |
|
|
|
| ▲ | WD-42 3 days ago | parent | prev [-] |
| I would say Javascript's lack of a standard library is at least in part responsible for encouraging npm use, things just spiraled out of control from there. |
| |
| ▲ | raffraffraff 3 days ago | parent [-] | | [not a dev] why isn't there the equivalent of "Linux distributions" for npm? I know I know: because developers all need a different set of libs. But if there were thousands of packages required to provide basic "stdlib-like functionality" couldn't there be an npm distribution that you can safely use as a starting point, avoiding importing asinine stuff like 'istrue' (yea I'm kinda joking there). Or is that just what bloated Frameworks all start out as? | | |
| ▲ | chha 3 days ago | parent | next [-] | | There could, this would essentially be in the form of a standard library. That would work until someone decides they don't like the form/naming conventions/architecture/ideology/lack of ideology/whatever else and then reinvent everything to do the same, but in a slightly different way. And before you know it, you have a multitude of distributions to choose from, each with their own issues... | |
| ▲ | rafaelmn 3 days ago | parent | prev | next [-] | | Who is shipping/maintainig this ? Even node itself is maintained by OSS. That's one of the advantages of Microsoft .NET ecosystem - you can do a lot of stuff without pulling anything not shipped by Microsoft. I don't know of any other ecosystem that's as versatile with so much first party support. Source available beats open source from a security perspective. | |
| ▲ | Sanzig 3 days ago | parent | prev [-] | | So basically, Boost for JavaScript? |
|
|
