leverage lodash

[jdalton]

I know @megawac is experimenting with lodash-es modules to reduce some of the lower level cruft so async can focus on other bits. I'm opening the issue here to give it a bigger spotlight and to encourage discussion/contribution to his experiments. Btw I'm totally open to helping in this area from the lodash side of things.

[aearly]

I"m totally 👍 on this, but we haven't figured out the best way to package multiple modules for the standalone browser build. (In addition to having npm deps, we also want to split up the singular async.js into one file per method.) The straightforward solution is to use browserify, but it adds a lot or overhead.

I wonder how @megawac 's experiments are going....

[jdalton]

For the experiments I retooled the lodash-es build to export modules so that something like

import chunk from 'lodash-es'

was doable to allow cherry-picking just the chunk method.

I know Graeme is experimenting with rollup to handle bundling.

[megawac]

So the basic idea is to default in using a modular build (i.e. a bunch of lib/<function>.js ala ramda but with third party module support) which all use CJS/ES6 imports for required async and lodash methods. A monolithic build (with a clever preprocessing step) would also be created using rollup.

Rollup doesn't seem quite ready yet, and runs into a couple issues with lodash-es at the moment -- I've been punting on doing a debug session to figure out whats up on that front.

[aearly]

ES6 seems like it will enable a lot of bundling optimizations -- e.g. when multiple modules depend on the same thing it can probably be pulled into a single var in a parent scope, in addition to cherry-picking single exports.

A shame you can't do it confidently today with browserify, since with var _ = require("lodash"), _ could be rebound later in the module, but in theory const _ = require("lodash") is something that could be pulled into the top-level scope for a bundle. With ES6 modules that export bindings, it seems that you'd always want to pull those export default bindings to the top level scope since they wouldn't change.

[jdalton]

@aearly
On a side note @megawac has a babel plugin to handle some of the syntax wins without es6.

Pulling in @Rich-Harris for the rollup related issue.

[aearly]

Yeah, that works really nicely for lodash, but it would be great to have something that works across the board for any lib that follows a couple conventions.

[Rich-Harris]

@megawac lmk if there's anything I can do to help figure out the problem(s) – am always grateful for test cases

[aearly]

I finally took a look at rollup, it seems really interesting! It looks like we could easily use it to build the core async lib from small ES6 modules, then perhaps use browserify or webpack to bundle in npm dependencies for the browser.

It looks like rollup isn't handling on export { default as slice } from './array/slice'; style declarations. I played around with rollup's in-browser playground, and it seemed to choke on that.

[megawac]

The biggest issue stalling adoption is to go over open pull requests and
accept or reject. After that we can start modularization + rollup
On Oct 22, 2015 2:41 AM, "Alexander Early" [email protected] wrote:

I finally took a look at rollup, it seems really interesting! It looks
like we could easily use it to build the core async lib from small ES6
modules, then perhaps use browserify or webpack to bundle in npm
dependencies for the browser.

It looks like rollup isn't handling on export { default as slice } from
'./array/slice'; style declarations. I played around with rollup's
in-browser playground, and it seemed to choke on that.

—
Reply to this email directly or view it on GitHub
#914 (comment).

[Rich-Harris]

@aearly interesting – any chance you could reproduce the bug so we can take a look? This seems to work but I'm probably missing something. Thanks!

[aearly]

@Rich-Harris I lost the tab where I was playing around with modules, and I can't seem to reproduce it. I probably was doing something that was actually an error. lodash-es6 is worth another shot.

@megawac I've gone through the majority of open pull requests. I think I might do a 1.5.0 release, then we can focus on some of these larger changes.

[megawac]

Good stuff @aearly!

[jdalton]

I updated the es build to separate the default exports into their own modules.

[aearly]

Closing this since we've done it in #996!