top | item 45189960

(no title)

RVuRnvbM2e | 5 months 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.

discuss

order

zer00eyz|5 months ago

> 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|5 months ago

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|5 months ago

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|5 months ago

> 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|5 months ago

“It’s not difficult to fix, just change the entire culture”

The difficulty comes in trying to change the entire culture.

aspenmayer|5 months ago

“Doctor, it hurts when I do this!”

“Stop doing that!”

“But I wanna!”

WD-42|5 months ago

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|5 months ago

[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?