Focused libraries that does 1 thing, and 1 thing well with 0 pain of setting it up, please. Really tired of dealing with tech stacks that claim to do all with the most modern/cool way with tons of config and gotchas while doing nothing out of the box.

Somewhere inbetween. I appreciate large do-everything libraries, but they're too large and include many many things I don't need. Small unopinionated libraries without enough things aren't very helpful either. I need a certain balance between the two.

Small, focused helper functions that can be combined with any number of other functions, in any combination.

The downside to bundling them all together is if you only want to use one part of it, you have to start making decisions about what to do with the code you intend not to use. Tree shaking? Custom build? Import anyway? With ES modules does it make sense to have to download a giant file only to read one function from it? etc.

I think, especially with the nature of JavaScript modules, that single-function helpers are probably the most flexible.

But, you raise a good point as well, sometimes there's a theme that ties a number of helpers together around a common task, a common purpose, or a common functionality. What are ways we can package up and market sets, series, or families of plugins together in a way where they can be used independently from each other too?

I prefer the smaller ones if possible. Rather simple logic ... less code, less possible bugs. :)

Actually you’ll need both for a healthy mix, even in smaller projects. Otherwise the application will tend to reflect to have the same disadvantages as the framework you’re using.

It depends.

Some advantages of small and focused libraries:

• Small components may be reusable. That's the big one.
• Code size is small, so perhaps the deliverable is too (although you could probably do dead code removal as part of compilation, especially in static languages).
• Code size is small, so it'll be easier to understand it.
• Less code means less trust is needed, e.g. for security.
• It encourages creating a common infrastructure that others can build on, e.g. pythons numpy or linux streams or js events.

Disadvantages:

• Some things are hard to split, e.g. unicode support.
• It's administration overhead - more repos, more versions, more interdependencies...
• It's annoying to pick the parts you need. Most people will just end up using packages of many small utils.
• Integration may be worse, e.g. a web server framework that comes with an ORM and router and template engine is more restrictive, but perhaps more symbiotic than a pluggable one.
• Having hundreds of small libraries could be confusing for users (although with a decent package manager it needn't be).
• Small libraries that are reused may conflict if they have different versions (although with a great package manager they might not).

It's all kind of a spectrum. Is "json encoding for all the most common types" doing one thing well? Is "all of regex" doing one thing well? Is "collection of useful stream operations"?

I considered making lexing, parsing, code generation etc separate packages for my compiler, but in the end I didn't, because they're mostly useless in isolation.

Often users can get the best of both words with packages that give a unified interface using independent components (kind of a Facade pattern).

I think in many cases, the ideal system for open source projects is like:

• A package with shared infrastructure (usually mostly interfaces or data types). Or several if separable. Should be very stable. E.g. streams.
• Many small inplementation packages that depend on the infrastructure. E.g. cat, grep, sed, wc... Mostly for other developers.
• A few (nested) collection packages that fairly directly expose many independent components, possibly with a little integration logic. 90+% of end users will use this.