Builds using esModules/Support Tree Shaking

(This issue tracker is only for bug reports or feature requests, if this is neither, please choose appropriate channel from http://bluebirdjs.com/docs/support.html)

Please answer the questions the best you can:

1) What version of bluebird is the issue happening on? All of them.

2) What platform and version? (For example Node.js 0.12 or Google Chrome 32) Every Platform/Every Version

3) Did this issue happen with earlier version of bluebird? Yes

(Write description of your issue here, stack traces from errors and code that reproduces the issue are helpful)

I’m not sure if this is already represented in the Bluebird pipeline, or I’ve missed another issue that captures this (I just searched for “tree-shaking”, entirely possible). If so, this can be closed.

It would be nice if Bluebird were bundled using a well-known module bundler, or could in some way capitalize on the tree-shaking functionality that many well-known module bundlers provide.

I am requiring Bluebird into a project of mine. It is quite large, but I am willing to include it because of the considerable speed advantages I get out of using it (seriously, awesome work). I am then using Webpack 2 (webpack@2.1.0-beta26) to bundle my project.

This project does not use any of the ancillary methods bluebird provides (map, filter, each, etc), but because the module is pre-bundled (using “fs”), I cannot shake any of the modules that are in the bluebird.js main.

In addition, I have tried explicitly including Bluebird in my build and referencing bluebird only from ‘bluebird/js/release/bluebird’:

loaders: [
    {
         test: /\.js$/,
         loader: 'babel-loader',
         exclude: /node_modules\/(?!bluebird)/
    }
]

import bluebird from 'bluebird/js/release/bluebird';

but this results in a build of exactly the same size. It appears as though a bluebird.core.js module is distributed as well, which is slightly smaller, but it also appears to not be as performant as the main module.

In addition, if there are any workarounds, I would love to try them out.

[benderTheCrime]

Also, as the node-bluebird steps to create a custom build suggest, this has to be done from a cloned instance of bluebird. There is no gruntfile associated with Bluebird, so actually adding this to my build pipeline does not work.

[benderTheCrime]

@spion I didn’t know that was a possibility, thank you for passing along these links.

Nevertheless, I would classify this under the “workarounds” I mentioned in my issue. It is nice to be able to conditionalize the optional modules based on a build, but it seems like a lot of work for a dependency within any project’s build lifecycle.

If I was to do this, I would have to explicitly add a statement to my build scripts that built bluebird without those modules every time my packages were resolved, and rebuild if my project starts to use one of the optional methods is called within my project (imposing some small amount of overhead).

Therefore, I think this is still a relevant issue to track. It’s unrealistic to expect users to create implementation-specific builds when there is a perfectly good vehicle to prevent them from having to do so.

Perhaps https://github.com/rollup/rollup/wiki/jsnext:main?