[build] Bundling with Rollup

• I have searched the issues of this repository and believe that this is not a duplicate. I believe the only relevant thing is this comment https://github.com/mui-org/material-ui/issues/8100#issuecomment-328078814:

  we would love to know if you can bundle the v1-beta branch with rollup.

Expected Behavior

Bundling with Rollup should work as long as MUI provides ES modules (https://github.com/rollup/rollup/wiki/ES6-modules#es6-friendly-libraries).

Current Behavior

Currently, there is an index.es.js file which is an ES module itself, but it points at CommonJS modules (https://unpkg.com/material-ui@1.0.0-beta.32/index.es.js). This then causes Rollup to fail to build:

[!] Error: 'BottomNavigationAction' is not exported by node_modules/material-ui/BottomNavigation/index.js
https://github.com/rollup/rollup/wiki/Troubleshooting#name-is-not-exported-by-module
node_modules/material-ui/index.es.js (9:38)
 7: export { default as Avatar } from './Avatar';
 8: export { default as Badge } from './Badge';
 9: export { default as BottomNavigation, BottomNavigationAction } from './BottomNavigation';
                                          ^
10: export { default as Button } from './Button';
11: export { default as ButtonBase } from './ButtonBase';

Presumably, this is because https://github.com/rollup/rollup-plugin-commonjs cannot fully understand the CommonJS exports (unless you manually specify them via namedExports option).

Steps to Reproduce (for bugs)

I have a simple repro available here: https://github.com/NMinhNguyen/material-ui-rollup-example

It also contains a branch where I modified yarn.lock to point at a temporary fork of MUI that publishes ES modules (source), and bundling with Rollup works without any other changes. I am willing to raise a PR with this change (I’ll probably also replace the current build:es2015modules script as I believe my change supersedes it, but not sure if removing index.es.js could be considered a breaking change?), but I thought I’d raise an issue first (this is also what the contributing guide suggests) 🙂

I have also created this branch where I committed the current build output and how it changes with my changes so you can more easily review them as well as spot any possible regressions. And here you can find the actual ES5 modules.

By the way, the reason I would rather not use the es folder is because that folder is ESNext (2015+), so I’d have to transpile it via Babel myself. This would mean that I’d additionally have to include these plugins to ensure I get the same Babel transformations applied: https://github.com/mui-org/material-ui/blob/8497cd976d74cfd102c6e8afb932348b366dd5b3/.babelrc#L70-L83

Context

We are using Rollup to bundle our code.

Your Environment

Tech	Version
Material-UI	1.0.0-beta.32
React	16.2.0
Rollup	0.55.3
rollup-plugin-commonjs	8.3.0

[oliviertassinari]

I still have a feeling that if a library ensures that its ES output only imports ES modules, then the risk of module duplication is significantly reduced?

@NMinhNguyen Yes, I agree with this point at the condition all the third party libraries you want to use follow this pattern. Hard to enforce.

would you be open to me raising a smaller PR that does just that?

Yes, please! I thought it was already done. It can be considered a bug on our end.

[estaub]

fwiw, here’s a different experience and motivation:

When using dynamic bundle loading, initial page-load gains can be very much larger than those @dantman’s showing above. My initial load mui stat size for about half of my pages is about 300K (30K gzipped). The other half need another bundle, with another 300K (22K gzipped) of mui. A few rarely-used components are sprinkled elsewhere in bundles where they are used. I’m just telling webpack 4 to split things up as it deems best; I’m not hand-tweaking all of this.

I’m trying to keep the app viable for use on slow devices with low bandwidth.