Support multiple Webpack files

[jimmcslim]

I like the idea of separate vendor and feature bundles, as described by K. Scott Allen at http://odetocode.com/blogs/scott/archive/2016/12/01/building-vendor-and-feature-bundles-with-webpack.aspx

However this requires support for multiple (2) webpack files (I think), could that be supported?

[KraigWalker]

The example projects already use multiple webpack files. In then prepublish area of the project.json, webpack.config.vendor.js and webpack.config.js are run. You can add more webpack files to the prepublish step if you want to.

[SteveSandersonMS]

@KraigWalker is correct that the default templates here already use two Webpack configs - one for vendor libs; the other for application code.

To implement the bundle-per-feature pattern as per K. Scott Allen's post, you already have everything you need (as far as I'm aware). He's only using two Webpack configs, and you'd only want to enable HMR on the config that produces the feature bundles. It's almost the same as the default setup you get with the templates in this repo. No extra special support is needed.

However there is also a more general question here. Can you have many independent Webpack configs (as opposed to many bundles)? Yes - just have as many UseWebpackDevMiddleware calls in your Startup.cs file as you need, and for each one, specify a different ConfigFile option value. This was already supported. You'll get as many separate Webpack dev middleware instances as you need.

What wasn't supported, until now, was having more than one Webpack dev middleware instance with HMR enabled. But I've now added a further option to enable support for this. When the updated version of Microsoft.AspNetCore.SpaServices is published, you'll be able to enable HMR on multiple Webpack dev middleware instances as long as:

• Each of them has a distinct publicPath value in the config, so that requests for the files get routed to the correct instance
• Each of them has a distinct HotModuleReplacementEndpoint URL configured on its WebpackDevMiddlewareOptions, so the client-side code will listen for updates on each of the instances separately