search

aurelia / loader-webpack

An implementation of Aurelia's loader interface to enable webpack.
MIT License
26 stars 10 forks source link

chore(build): do not bundle HMR when not needed #32

Closed jods4 closed 7 years ago

jods4 commented 7 years ago

I have cut the static dependency on aurelia-hot-module-reload and moved it inside the if (module.hot) branch. This is detected by Webpack, so that aurelia-hot-module-reload is only bundled when compiled with --hot. This helps reduce the size of production builds.

One thing that I'm not happy with is the literal typing of field hmrContext. But to improve that I think we need to export HmrContext definition in the DTS of aurelia-hot-module-reload in a way that can be consumed from the DTS only with no import (e.g. define in a namespace rather than a module?).

niieani commented 7 years ago

I was thinking about this originally when adding HMR. Wouldn't aurelia-hot-module-reload get removed by the tree-shaking algos, if there are no calls to it after importing... given that any usage will be stripped out by Webpack and uglify in production mode.

jods4 commented 7 years ago

I observed (as can be seen in the treemaps that I posted in aurelia/framework#692) that it was still there after tree shaking.

I am not sure if webpack removes imports that are not used in the code (to in turn remove the exports)...

Even if it did, in this case the import is used, albeit in a if (false) branch. Webpack does some flow analysis to decide which dependencies are needed, but it does not evaluate everything.

It could do all that but as of 2.2.0 it doesn't seem to.

EDIT: or maybe it does, because there's another layer of badness: Removing the import/exports is not everything. It would turn the import to import "aurelia-hot-module-reload", which is kept for its possible side-effects. Webpack tries to completely remove modules, but it needs to prove that they don't have side-effects and very often this is not possible.