Consider splitting the package out across multiple packages / modules

Both async and underscore currently suffer from being a “kitchensink” of anything possibly uesful, these modules didn’t start out that way but more and more stuff was added to it.

Projects like lodash or underbar have mitigated against this effect by splitting the module out across multiple modules / packages. @jdalton & @Matt-Esch have done good work to allow usage of the functionality piece by piece.

This allows consumers of the module to use a tighter subset of the functionality.

@gozala also had a similar approach with splitting out reducers and reducible and then a set of optional functions all over npm like buffer-reduce , tree-reduce , dom-reduce and others.

There probably is still value in having a module that combines everything together in a “kitchensink” for people that prefer that just like lodash allows you to get it all or get the functions one by one.

[DamonOehlman]

Taking a look at underbar I’d definitely 👍 going with that approach over others.

Personally, I love being able to communicate to someone “Hey, you should go try highland.js” and also this involves is them having to:

a. look at the highland.js project page / website b. start using it in their projects (be it node or something browserified) by simpling installing one package (npm install highland --save)

Then using the intelligence of browserify’s static analysis to only bring in the functionality that is required based on what I have used is fantastic. I agree that the work done with lodash is an improvement on the kitchen sink approach, but my personal opinion is that using that approach creates a lot of module pollution. While I’m sure npm can handle all those separate modules, I’m not sure that it’s efficient way for us to communicate as humans. Just my 2c - but it’s 2c I’m pretty passionate about…

[Majiir]

+1

I wanted to use batchWithTimeOrCount today, but I was surprised to see that I would have to include the entire library in my Browserify bundle.