can confirm.

There’s nothing for us to do about it on our end, this is an unfortunate reality of the front-end build ecosystem. While phoenix.js uses webpack to produce the es6/commonjs module, we have zero runtime dependency on the compiled phoenix.js. The out-of-the-box experience that mix phx.new gives you uses babel for ES6/2015/whatever compilation, (thru brunch <= 1.3, and now webpack in 1.4+), but it includes no other deps other than the js compiler, and css concat packages. The rest are just the rabbit hole of deps of wepback, babel, et al.

Read this : https://medium.com/@jdan/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558

Welcome to to the insanity of front-end development!

I’ve never bothered to look into this before, but I assumed the main culprits would be brunch and babel. From a cursory glance it seems like the ‘phoenix’ dependency depends on these too though, so I suppose it’s all just one big mess (perhaps Chris McCord can correct me about this?).

There’s a bunch I could say about how I try to keep things simpler, but the truth is that I find this really difficult to do in practice. Any particular package is likely to use a ton of others, and this insane dependency graph just grows from there. Something like Webpack or Babel is pretty essential to most of what I do, for example, but both of these, or at least Webpack, pull in tons of other dependencies.

All that said, I would very much prefer if ‘phoenix’ and ‘phoenix_html’ avoid this, so I can try and figure out how to make the rest of my front-end stuff not end up with this insane number of dependencies.