Repository navigation
webpack.config.vendor.js and Tree-Shaking #195
Description
Activity
Yep, I totally agree with your suggestion. Tree-shaking is only applicable to production builds, because with dev builds, your set of dependencies can change at any time, and you don't want to wait for re-processing all the vendor files after you make each change to your code.
One additional thought: for production builds, I still think there's benefit in splitting the output into
yourcode.jsandvendor.js(wherevendor.jsis tree-shaken based on the usage fromyourcode.js), rather than having the build just output a single merged file. This is because, for most changes to your code, you probably don't change your set of vendor dependencies, so the tree-shakenvendor.jswould remain identical. Then clients don't need to re-fetch thevendor.jscontent if they already have it cached (they'll either get a 304 Not Changed or they won't even make a request for it, if you're referencing that file using some content-based address (like?hash=blah) as is the default with the templates in this repo). I don't yet know whether Webpack 2's tree-shaking does that, but we can always adapt to whatever is supported.Closing because it doesn't seem that there's any action to take on this right now, but this is a useful discussion point for when Webpack 2 ships and we switch over to it. Thanks for raising this!
No worries and agree with your comments.
@SteveSandersonMS Does it still make sense for Angular to be in vendor bundle if using AOT?
@mcm-ham It might not do. We'll find out when it's implemented :)
AOT should also only be done at production and is required for Tree Shaking to fully work because the HTML has to be bundled into javascript as does the (s/l)css.
The key is to just use vendor splitting at dev time OR use a merge tool in webpack to put them back together before doing AOT and tree shaking.
@SteveSanderson Now that tree shaking seems to be implemented (as per https://webpack.js.org/guides/tree-shaking/), is there any interest in revisiting this? Or should the discussion be moved to https://github.com/aspnet/templating since the templates are no longer in this repo?
@ToucheSir We're moving the templates to use whatever is the default setup for each SPA framework. For example, the Angular template will be the standard setup for an Angular CLI app, and the React template will be the standard setup for a create-react-app app. Once this is the case, the Webpack config (if any exists, usually not) will no longer be something we made any decisions about - we just use whatever the SPA framework guides people to use. As for tree shaking, I believe Angular enables that out of the box. Can't remember about React.
As an observation, how will
webpack.config.vendor.jswork as Tree-Shaking becomes more common. Quickly looking atwebpack.config.vendor.jsit doesn't seem to have knowledge about whats being used vs not... If this is the case, maybe the prod build could work in vender dependencies there (hencewebpack.config.vendor.jsis only used at dev time) andwebpack.config.prod.jscould output the vendor as a separate file then, hence getting the best of both worlds.