[dvcrn]

Small composable packages aren’t a bad thing IMO. It’s nice to pull things together how you want without having to reimplement the same logic multiple times. Just encapsulate smaller bits of useful code into their own mini packages

Like if there’s some string manipulation thing I need, instead of copy pasting some snippet, I can pull in the micro package that already does this

[ufmace]

I'm going to have to disagree with that. Micropackages may seem nice at first, but they're a nightmare to manage longer-term mostly due to low-skill project management. Many such packages make breaking API changes, sometimes without obeying SemVer standards. Some are effectively abandoned, and don't get updates for regular bugs, security issues, etc. Sometimes the lone developers responsible for them may delete them in a fit of pique (left-pad anyone?). Sometimes they get taken over by malicious entities who might add obvious or subtle malware to it. I'm pretty sure all of these have happened already.

That's not even what's important though. What's important is, how can you ensure that none of these things happen to any of *your* projects dependencies? It's virtually impossible when there's a thousand of them. Are you going to audit that string manipulation micro package when you first add it, and then for every version update from now on, to ensure that nobody slipped some subtle malicious code into it? And do the same for every other micro package in your project, including all of the ones that the big ticket packages depend on?

All of this would be much less relevant if it had a more fully-featured standard library.

[cute_boi]

makes sense in some situation but people seems to forget left pad fiasco. And the small package which you say sounds good in theory but what we get is bloated things that depends on multiple semver package. And many developers don't even have a clue whats happening which algorithm it is using and thats fair if you get millions package in nested dependencies.

However in Rust I find these packages managed properly which npm should learn.

[linkdd]

> which npm should learn

More like "which the JS/TS developers should learn from"

npm is just a package manager, it's not its fault.

[hdjjhhvvhga]

The thing is, many other modern ecosystems have these included. You don't need a pile of dependences because you are guaranteed to have the functionality you need. Of course you will still need modules for more specific things but since the most often used functionality is already there you end up with ten packages, not a hundred or more.

[PKop]

How is this an argument against a larger standard library?