4 ms·

I love this, but I'm missing a key piece to make this effective for non-tiny code bases. The author proposes using 2 webpack configs, one for es2015 and one fo

I love this, but I'm missing a key piece to make this effective for non-tiny code bases. The author proposes using 2 webpack configs, one for es2015 and one for es5. That means running webpack twice from scratch. This, in turn, means you can't effectively use webpack's devserver because that's just a single instance with a single webpack config. The author's boilerplate [0] "solves" that by hand-coding a watcher based on chokidar which just rebuilds both files on every change. On our code base, clean webpack builds take minutes (and when babel is even configured to exclude /node_modules/, as the author recommends against). If we'd follow the author's advice, we'd be waiting for minutes every time we make a change. Anyone got a good idea here? The best I can come up with is to use the es2015 build (but with node_modules excluded) in dev mode, and then for staging and production, running webpack twice as the author suggests. That makes the dev version rather different from both the production es2015 output and the production es5 output, however, so if there's any bug in the chain anywhere (babel bug, webpack bug, babel-env browser support table error, etc etc) we may not always find it. In all honesty that itches me a bit (even though by skipping uglify in dev mode we already depend on at least 1 tool being essentially bug-free). Any ideas? [0] https://github.com/philipwalton/webpack-esnext-boilerplate https://github.com/philipwalton/webpack-esnext-boilerplate

philipwalton 9y ago
You're right about it not working for webpack dev server, and I agree that it's unfortunate, but I think webpack will evolve to accommodate this. [EDIT: it looks like this is already supported, here's the documentation explaining how to do it: https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations https://webpack.js.org/configuration/configuration-types/#ex...] Service Worker already introduced the need (or you could argue possibility) to have multiple configs since SW code has a much different transpiling baseline compared to legacy browser code. And module code just adds one more level to this. I think webpack dev server will update if this practice becomes popular, but for the moment I think your idea of only building the es2015 build in dev mode is probably the best temporary solution (as long as you make sure to run your test suite in multiple environments and include the legacy build there).
Touche 9y ago
Test your production builds, that's the solution. Both with unit tests (in CI) and sanity testing.
crooked-v 9y ago
Actually, I believe you can already run webpack-dev-server with a multi-config just by making your webpack.config.js export an array instead of a single object. The article seems unaware of this capability, but you should be able to have both builds be part of a single webpack config file. See https://github.com/webpack/webpack-dev-server/blob/master/examples/webpack-config-array/webpack.config.js https://github.com/webpack/webpack-dev-server/blob/master/ex... for a simple example. I've used this before for web worker scripts (which require a different environment than the DOM) alongside a normal build.
- philipwalton 9y ago
  I didn't know about that. I'll look into it!

philipwalton 9y ago

You're right about it not working for webpack dev server, and I agree that it's unfortunate, but I think webpack will evolve to accommodate this. [EDIT: it looks like this is already supported, here's the documentation explaining how to do it: https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations https://webpack.js.org/configuration/configuration-types/#ex...] Service Worker already introduced the need (or you could argue possibility) to have multiple configs since SW code has a much different transpiling baseline compared to legacy browser code. And module code just adds one more level to this. I think webpack dev server will update if this practice becomes popular, but for the moment I think your idea of only building the es2015 build in dev mode is probably the best temporary solution (as long as you make sure to run your test suite in multiple environments and include the legacy build there).

Touche 9y ago

Test your production builds, that's the solution. Both with unit tests (in CI) and sanity testing.

crooked-v 9y ago

Actually, I believe you can already run webpack-dev-server with a multi-config just by making your webpack.config.js export an array instead of a single object. The article seems unaware of this capability, but you should be able to have both builds be part of a single webpack config file. See https://github.com/webpack/webpack-dev-server/blob/master/examples/webpack-config-array/webpack.config.js https://github.com/webpack/webpack-dev-server/blob/master/ex... for a simple example. I've used this before for web worker scripts (which require a different environment than the DOM) alongside a normal build.

philipwalton 9y ago
I didn't know about that. I'll look into it!