Feature/es6 module build

[neeharv]

HACK ALERT. This is an extremely WIP hacky way to do split builds into ES6 and ES5 builds, as described in #3125. I am simply putting this up to spark discussion on the right way to do this.

This works by -

1. Turning webpack.prod.js into a factory function that takes in target and returns different configs with varying targets
2. We suffix the module build assets with .es6.js (this can be moved to config easily)
3. For the ES6 build, we don't include polyfills
4. We get 2 asset-manifests this way, and hence 2 different service workers that load the relevant built code
5. Switch over to "uglifyjs-webpack-plugin": "^1.0.0-beta.2" so we can minify the ES6 code
6. It currently only spits out the ES6 build only in this PR, because the HtmlWebpackPlugin looks at webpack's stats file to generate the variables for the template. I have a local version of HtmlWebpackPlugin that reads the assets of both builds and makes them available for the template, but that is beyond the scope of this and an extremely bad way of doing things

An alternate to this would be to somehow get webpack to accept two different loader configurations for two different entry points, in the same build. AFAIK, this is what @geelen was trying and webpack today doesn't support this. Hence the above approach of running two parallel builds and then using a custom templating job to add the asset names of the ES5 and the ES6 code to the output html.

[viankakrisna]

I think #3103 could be the first step towards this

[viankakrisna]

changes in #3103 would make this less hacky IMO

[diligiant]

Isn't babel 7.0 babelrc.js a solution to this?

[neeharv]

@diligiant Not really, because as I mentioned below, both .babelrcand babelrc.js are required once and then cached. So can't switch things in them based on env variables for eg.

[diligiant]

@neeharv you mean there is no way you could offload the configuration to babelrc.js, invoking it yourself, in order to “preserve” some kind of consistency in regard to how Babel will be usually configured from now on?
(Not sure I make myself understandable ;)

[neeharv]

I explored the option of doing this with different babel environments, but if you're running two builds, the babel config is cached the first time. So even after that lands and we're able to pass babel env, it won't be useful unless we delete the the require cache for the babel config file.

…

On Fri 15 Sep, 2017, 5:59 PM Ade Viankakrisna Fadlil < ***@***.***> wrote: I think #3103 <#3103> could be the first step towards this — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3136 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsS4QShWUxwZObrCYgN-sq6V3Qc3Sl2ks5sim27gaJpZM4PY4AJ> .

[philipwalton]

Awesome to see this being implemented! A few issues I noticed:

1. You're going to need to inline the nomodule fix somewhere in the HTML for Safari 10.x, otherwise it'll execute both files.
2. You're also going to need to add the {mangle: {safari10: true}} config option to the UglifyJSPlugin() or you'll get syntax errors in Safari due to bugs in its ES2015 variables implementation (which have since been fixed). You can reference how I do it in my boilerplate for an example.

[icopp]

An alternate to this would be to somehow get webpack to accept two different loader configurations for two different entry points, in the same build.

If you give webpack an array of objects rather than an object, it will run all of them. They're effectively separate builds (even if you're outputting to the same folder), but webpack-dev-server will live update both and so. See their example of doing such.

Also, for my part I'm wondering if .mjs as an extension wouldn't be better.

[neeharv]

@icopp true, but then two separate manifests are spat out, which is the problem. We want a combined manifest with two different configurations for two different entry points, because our final HTMLWebpackPlugin will inline filenames from the manifest

[diligiant]

@icopp both configs are marginally different which makes @neeharv and @philipwalton approach DRY.

[icopp]

@neeharv There are already two asset manifests being generated with the current version, unless I'm missing something. Using a single config that's an array still has that problem, but it lets you use the webpack dev server, which running things as two separate builds doesn't.

@diligiant You can generate two objects in an array dynamically from a single config and then pass the final result in to Webpack, though.

[diligiant]

@icopp my bad, I thought you were willing to have 2 webpack.prod.js files (dev and prod are very different so it makes sense to maintain 2 files). That's a great idea.

[neeharv]

@icopp good points, I'll switch this over to the array build so we can use dev server. As I commented earlier, the merging of the two manifests is the biggest unsolved problem and what I need help with. I have a version of HTMLWebpackplugin locally that very hackily works with multiple manifests but obviously that is not the ideal way to do this. It'd be best if webpack itself can spit this out, or we use a custom build system for the HTML and not HTMLWebpackplugin

[geelen]

Hmm, I still think the two webpack builds is not the way to go. The fact that you're trying to merge manifests (or load them both) feels like a warning sign. Is the main blocker to a single webpack build just the babel env caching stuff?

[rayshan]

@neeharv thanks for experimenting with this. Can it be closed in favor of #4964?

[dandv]

@rayshan: #4964 was closed yesterday.

[rayshan]

@dandv by mistake, reopened.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This pull request has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue. Thank you for your contribution!