> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past.
It's not wrong, but this take is kind of tired and well out of date. For about a decade or so left-pad's functionality has been standard in all browsers or runtimes. Plenty of other micropackages have been obsoleted as well and the current zeitgeist is to avoid publishing or using any sort of micropackage.
"Zero dependencies" is now a top marketing term in the frontend world. Unfortunately, their removal is an ongoing process and it's taken way too long already to fully purge the ecosystem of these packages. However, it's not because the JavaScript community has never thought of this issue before. "Add more features to the JS standards and don't use is-number" is not a particularly new idea or valuable insight.
But beyond that, there were plenty of not-tiny packages impacted as well. Continuing to beat this dead horse may be fun, but it distracts from the actual issue here.
It's also an effort being stymied by a handful of bad actors.
Case in point: one very prominent individual taking ownership of projects and inserting his libraries as dependencies. It then turns out he has a financial interest in increasing their download counts: https://github.com/A11yance/axobject-query/pull/354
Have been seeing these rants since the incident. Yet no concrete suggestions. Just high level hand wavy stuff like "better package management". What does that mean? We already have mandatory 2 factor, private npm registries.
Ultimately the reason the ecosystem is so fragile is because a ton of packages are maintained by solo devs. So it only takes one hack to impact a ton of code bases.
The only thing I can think of to prevent this is automated LLM scanning of every npm package when any dependency or subdependency (and that's its own gnarly tree) is updated.
There are a bunch of concrete suggestions in the article:
"By introducing universal signatures for packages of executable code, smaller channels and webs of trust, reproducible builds, and the many other straightforward, obvious techniques used by responsible package managers."
I'm as pessimistic as the author, though, about how those suggestions will be received.
I was going to say that I'm building apps in Deno which are outside the npm ecosystem -- the issue is these days that Deno supports npm deps now so you risk someone in your supply chain using npm and suddenly one is exposed again.
I just try to stick with Deno Standard Library since that is self-contained.
Oh, this old chestnut. "Just do what the distros do".
OK, sure, let's pencil this out.
Debian has ~1k volunteers overseeing ~20k packages. Say the ratio is 20:1.
npm alone -- not counting other ecosystems, just npm -- has 3 million packages.
So you'd need 150k volunteers. One hundred and fifty thousand unpaid individuals, not counting original authors.
For one repo.
"Nonsense", you riposte. "Only maybe 100k of these packages are worth it!"
Cool, cool. Then you'd need "only" 5 thousand volunteers. Debian maxed out at 1k and it is probably the source of the most-used software in history. But sure, we'll find 5 thousand qualified people willing to do it for free.
Oh, but how do you identify those 100k packages? OK, let's use download count. Or maybe reference count. Network centrality perhaps? Great, great. But some of them will be evicted from this paradise of rigorous repackaging. What replaces them? Oh, shoot, we need humans to go over up to 3 million packages to find the ones we want to keep.
What I need distro boosters to understand is that the universe of what is basically a package manager for large C libraries is at least two orders of magnitude smaller than everything else, bordering on three if you roll all the biggest repos together. The dynamics at language ecosystem scale are simply different. Yelling at the cloud that it should actually be a breeze isn't going to change things.
There are probably 5k libraries and frameworks worth paying attention from OSS community and organization structure similar to Eclipse Foundation or Apache. The rest is either junk, low risk solo maintained project or corporate stuff maintained by someone on salary.
It’s not great. If an urgent security patch needs to be applied, the package must be excluded entirely from the minimum age requirement. There is no way to allow just a single version.
Fundamentally, the fix isn't technical; it's social / structural.
Companies either hold themselves accountable for signing off on the dependencies they use, hold the repos accountable for signing off the dependencies, or keep doing what we've been doing.
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of [X].
> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn.
This is as big as a strawman as I can imagine. Both of these "solutions that won't happen" are already happening:
- The ECMAScript standard already defines a `Strong.padStart()` as part of the "real" standard library of Javascript [1]
- There is a very well known larger package that combines many micro-utilities like this into one, lodash [2]
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of software development.
Really seems like the author wants to hate on the ecosystem for the sake of hating on it.
The author is clearly not talking about left-pad like that library is still specifically an issue. He's raising it up as an example of a problem that is still occurring. He then makes the point that maybe we should have less packaged JS code in general and that more software solutions should exist (and should have always existed) as part of the standard library or well-maintained packages like Lodash (although he doesn't reference it by name, just the concept it exemplifies). It feels like you've missed the forest for the trees.
Yeah, we’re at the point now where people saying left-pad isn’t fixed is more of an indicator that they aren’t paying attention. I’ve largely stopped correcting people, as it’s clear there’s a sizable community that just likes being grumpy about JS and doesn’t appreciate reality barging in to ruin the fun.
Won’t this be solved fairly soon when package managers have automatic scanning of updates by AIs that are superhumanly good at spotting malicious code?
Not sure if this is sarcastic, but this is a terrible idea. Best case scenario, it relaxes human vigilance and turns the success of malicious code attacks into a dice roll. More likely is that obfuscation techniques designed to fool LLMs will open the flood gates for malicious code.
> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past.
It's not wrong, but this take is kind of tired and well out of date. For about a decade or so left-pad's functionality has been standard in all browsers or runtimes. Plenty of other micropackages have been obsoleted as well and the current zeitgeist is to avoid publishing or using any sort of micropackage.
"Zero dependencies" is now a top marketing term in the frontend world. Unfortunately, their removal is an ongoing process and it's taken way too long already to fully purge the ecosystem of these packages. However, it's not because the JavaScript community has never thought of this issue before. "Add more features to the JS standards and don't use is-number" is not a particularly new idea or valuable insight.
But beyond that, there were plenty of not-tiny packages impacted as well. Continuing to beat this dead horse may be fun, but it distracts from the actual issue here.
It's also an effort being stymied by a handful of bad actors.
Case in point: one very prominent individual taking ownership of projects and inserting his libraries as dependencies. It then turns out he has a financial interest in increasing their download counts: https://github.com/A11yance/axobject-query/pull/354
I've already heard suggestions in my org that we begin to use LLMs to generate entire NIH stacks from the ground up. I'm tired boss.
> my org that we begin to use LLMs to generate entire NIH stacks from the ground up. I'm tired boss.
It's all fun and games until DeepSeek starts checking if it's used inside an $enemy_of_state_org and generates subtle backdoored or buggy code.
Sounds plausible - it's already half way there.
Have been seeing these rants since the incident. Yet no concrete suggestions. Just high level hand wavy stuff like "better package management". What does that mean? We already have mandatory 2 factor, private npm registries.
Ultimately the reason the ecosystem is so fragile is because a ton of packages are maintained by solo devs. So it only takes one hack to impact a ton of code bases.
The only thing I can think of to prevent this is automated LLM scanning of every npm package when any dependency or subdependency (and that's its own gnarly tree) is updated.
> Yet no concrete suggestions.
There are a bunch of concrete suggestions in the article:
"By introducing universal signatures for packages of executable code, smaller channels and webs of trust, reproducible builds, and the many other straightforward, obvious techniques used by responsible package managers."
I'm as pessimistic as the author, though, about how those suggestions will be received.
Why are more people not talking about alternatives? https://jsr.io/docs/trust
I was going to say that I'm building apps in Deno which are outside the npm ecosystem -- the issue is these days that Deno supports npm deps now so you risk someone in your supply chain using npm and suddenly one is exposed again.
I just try to stick with Deno Standard Library since that is self-contained.
Oh, this old chestnut. "Just do what the distros do".
OK, sure, let's pencil this out.
Debian has ~1k volunteers overseeing ~20k packages. Say the ratio is 20:1.
npm alone -- not counting other ecosystems, just npm -- has 3 million packages.
So you'd need 150k volunteers. One hundred and fifty thousand unpaid individuals, not counting original authors.
For one repo.
"Nonsense", you riposte. "Only maybe 100k of these packages are worth it!"
Cool, cool. Then you'd need "only" 5 thousand volunteers. Debian maxed out at 1k and it is probably the source of the most-used software in history. But sure, we'll find 5 thousand qualified people willing to do it for free.
Oh, but how do you identify those 100k packages? OK, let's use download count. Or maybe reference count. Network centrality perhaps? Great, great. But some of them will be evicted from this paradise of rigorous repackaging. What replaces them? Oh, shoot, we need humans to go over up to 3 million packages to find the ones we want to keep.
What I need distro boosters to understand is that the universe of what is basically a package manager for large C libraries is at least two orders of magnitude smaller than everything else, bordering on three if you roll all the biggest repos together. The dynamics at language ecosystem scale are simply different. Yelling at the cloud that it should actually be a breeze isn't going to change things.
There are probably 5k libraries and frameworks worth paying attention from OSS community and organization structure similar to Eclipse Foundation or Apache. The rest is either junk, low risk solo maintained project or corporate stuff maintained by someone on salary.
Pnpm has a new setting to stave off supply chain attacks
https://news.ycombinator.com/item?id=45286526
yarn feat: implement npmMinimumReleaseAge and npmMinimumReleaseAgeExclude config options
https://github.com/yarnpkg/berry/pull/6901
It’s not great. If an urgent security patch needs to be applied, the package must be excluded entirely from the minimum age requirement. There is no way to allow just a single version.
Fundamentally, the fix isn't technical; it's social / structural.
Companies either hold themselves accountable for signing off on the dependencies they use, hold the repos accountable for signing off the dependencies, or keep doing what we've been doing.
The third option is amortized cheapest.
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of [X].
[X]
"software development"
"climate change"
"healthcare reform"
"political polarization"
...
> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn.
This is as big as a strawman as I can imagine. Both of these "solutions that won't happen" are already happening:
- The ECMAScript standard already defines a `Strong.padStart()` as part of the "real" standard library of Javascript [1]
- There is a very well known larger package that combines many micro-utilities like this into one, lodash [2]
> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of software development.
Really seems like the author wants to hate on the ecosystem for the sake of hating on it.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://lodash.com/
The author is clearly not talking about left-pad like that library is still specifically an issue. He's raising it up as an example of a problem that is still occurring. He then makes the point that maybe we should have less packaged JS code in general and that more software solutions should exist (and should have always existed) as part of the standard library or well-maintained packages like Lodash (although he doesn't reference it by name, just the concept it exemplifies). It feels like you've missed the forest for the trees.
Yeah, we’re at the point now where people saying left-pad isn’t fixed is more of an indicator that they aren’t paying attention. I’ve largely stopped correcting people, as it’s clear there’s a sizable community that just likes being grumpy about JS and doesn’t appreciate reality barging in to ruin the fun.
Won’t this be solved fairly soon when package managers have automatic scanning of updates by AIs that are superhumanly good at spotting malicious code?
Not sure if this is sarcastic, but this is a terrible idea. Best case scenario, it relaxes human vigilance and turns the success of malicious code attacks into a dice roll. More likely is that obfuscation techniques designed to fool LLMs will open the flood gates for malicious code.