Optimize the library for webpack users

[iamakulov]

Hey there! I optimized the library for users who build their browser apps with webpack. webpack is super-popular in front-end development, so that should be a large percent of browser users.

In my tests with map/parallel methods, the library size dropped from 28 to 12 minified kB (−57%). Here’s the repo if you want to reproduce: iamakulov/async-optimization-repro

This is a part of my performance consulting. I help open-source projects (for free) and companies (for money) to optimize the performance of their products: iamakulov.com/perf-consulting

---

The problem
Right now, when you import async into the app, you import all the methods it includes. So even if you only want to use .map, your app receives all 78 async methods:

import async from 'async';
async.map(...);
// All other methods are present at `async`, even if you don’t need them

Usually, this is solved by importing only the necessary methods:

import { map } from 'async';
map(...);

However, in case with async, this doesn’t help because the async’s entry point, dist/async.js, is a bundle with all the library’s code.

Right now, there’s no easy solution to this problem except doing import map from 'async/map', but that’s not very obvious.

The solution
I added a few flags that hint webpack how to optimize the library:

• Added "module": "lib/index.js" into package.json
  When the module field is present, webpack uses it instead of main to determine the entry point into the lib. With module, webpack would consume ES modules and drop unused code with tree shaking.

• Added "sideEffects": false into package.json
sideEffects: false tells webpack that library modules don’t have any side effects (e.g., don’t modify any globals). Webpack uses this info to remove the module if it’s reexported but not used. This improves the effect of tree-shaking.

• Removed lib from .npmignore
  Webpack users would need this directory, so we’ll need to publish it to npm.
  This has a drawback – the module would get larger and take longer to install – but, as a benefit, browser users would spend less time downloading it. Browser downloads happen more often than npm installs, so I believe this is for good.

• Documented the browser usage in readme. Docs are located at http://caolan.github.io/async/, but I’ve thought the performance considerations are important enough to place the snippet in the readme (many users won’t get into docs far enough to read it there). If you don’t want this change, I’d be happy to move it elsewhere.

(Sorry for ads in the beginning, I do freelancing for living)

[iamakulov]

(I’d also be happy to copy & expand the webpack section into http://caolan.github.io/async/ if this gets merged.)

[aearly]

This repo is really used to build 2 modules: async and async-es. If you run make build, it will generate build/ and build-es/ that are exactly what we publish. We already perform similar optimizations to what you propose.

Unfortunately, the package.json in the root is a bit of a red herring -- it is only there so we can continue to support people who use this repo as a git dependency. (otherwise, we wouldn't check in dist/ at all)

[iamakulov]

Lol. I should’ve looked for that repo :D

I’ve just tried testing this with async-es though, and while the bundle is smaller (16.3 kb vs 28; that’s great!), it doesn’t have the sideEffects: false flag. Adding the flag decreased the bundle down to 11.3 kb.

1. I’d still add the sideEffects: false flag into the async-es’s package.json. Are you open for that?

2. As far as I understood, READMEs are shared between the packages. Would it make sense to link to both async and async-es in the readme, so that users can find the version they need?

A-la “This project exists in two versions. If you use Node.js, install async – it’s built with CommonJS modules out of the box. If you build for web, use async-es – it’s optimized for webpack”

(Ideally, I’d add two different READMEs with slightly different code examples tailored for each version. If you’re open for that, I could tune the build process to do that)

[aearly]

Both 1 and 2 would be great. We do a bad job of advertising the existence of async-es right now.

[iamakulov]

Just force-pushed the updates. Looking forward to your review :–)

[hargasinski]

nit: this should be import { forEachOf } from "async-es";

[iamakulov]

Whoops, thanks! Fixed

[hargasinski]

Aside from one small typo, looks good.

[iamakulov]

(Pushed fixes a few days ago :–)

[hargasinski]

Merged, thanks!