Deploy both ES5 and ES2015+ code in production

Is this a bug report?

No

Everything described in this article.

But for lazy ones I’ll add some highlights here.

<!-- Browsers with ES module support load this file. -->
<script type="module" src="main.js"></script>

<!-- Older browsers load this file (and module-supporting -->
<!-- browsers know *not* to load this file). -->
<script nomodule src="main-legacy.js"></script>

Warning! The only gotcha here is Safari 10 doesn’t support the nomodule attribute, but you can solve this by inlining a JavaScript snippet in your HTML prior to using any <script nomodule> tags. (Note: this has been fixed in Safari Tech Preview, and should be released in Safari 11).

And here is the working example.

[MidnightDesign]

…so this is dead? Has anyone built like a plugin or something? I would really love to have this feature for performance and debugging.

[geelen]

Ok, after a few hours of hacking, this is what we’ve found:

• It can’t be two entry points

This feels like the nicest idea, where you now have two entry points (in webpack.config.prod.js):

- entry: [require.resolve('./polyfills'), paths.appIndexJs],
+ entry: {
+   main: [require.resolve('./polyfills'), paths.appIndexJs],
+   esmodule: paths.appIndexJs,
+ }

But there’s no way to change babel-preset-env in the config, depending on the entry point.

• Generating two webpack builds kinda sucks, but is maybe necessary

If you duplicate your production webpack config, you can handle things pretty well, but that has the weakness of… well… duplicating your production webpack config. @neeharv has gotten a build working pretty well using this so I might let him describe it.

One thing worth pointing out is that we had to use the beta version of UglifyJSPlugin to get the ecma config property, otherwise ES6 code would break. So CRA would probably need to bump to whatever version of webpack includes this, once it goes stable.

• Adding a post-processing webpack plugin to generate an ES5 version could work

This is where my thinking is at atm. If your webpack plugin targets beautiful new ES6 code with no polyfills and very little transpilation, but then something comes along and transpiles it to ES5. I’ve played around with unminified-webpack-plugin a bit and tried to get something similar working, but don’t know webpack really well enough to ship this quickly. What it would need to do, though, is this:

• Receive every JS chunk
• Rerun babel on it with a preset-env of older browsers
• Emit new chunks (with any dynamic imports rewritten)
• Name them as .nomodule.js or something similar
• Somehow instruct HTMLWebpackPlugin to inject the right script tags (type="module" for index.js, nomodule for nomodule.js)

This does feel like an achievable goal, and makes sense to be done as a webpack plugin. There are still questions around serviceworker, given that it reads from the manifest, but we haven’t got that far yet.

---

So that’s where we got to in a couple of hours hacking. I think this is a really cool idea and has the potential to dramatically cut down bundle sizes for modern browsers, so would love to see this progress!