I saw that my newly created (mix phx.new) project had a rather large assets/node_modules folder.
At a closer look it turns out it contains 7404 out of the entire projects total of 8827 items at roughly 2/3 of the total 31 MB.
I just created it and have everything from phoenix_html (which seems perfectly legit) to such as coffescript and snapdragon_util.
Do I have some crazy node settings (not a huge node champion) or is this normal.
If normal, is there a way I can drop all irrelevant packages?
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.
If normal, is there a way I can drop all irrelevant packages?
By definition if its there, its relevant to something you installed.
Basically ignore any bloat that is a result of the tooling (brunch/webpack, plugins/loaders) that you use to create your frontend JavaScript bundle.
But be extremely vigilant about any dependencies that you include inside your bundle (i.e. the JS libraries that you use inside the browser).
Even with tree shaking it can be extremely difficult to remove bloat. For example RxJS 6 dropped direct support of Observableobject methods in favour of independent operator functions partially to aid tree shaking in creating smaller bundle sizes.
I see it as the extreme counter to the Not Invented Here syndrome. So extreme that libraries are included as dependencies for a product even if only an infinitesimal fraction of a library’s functionality is used - potentially leading to a lot of recursive bloat.
Some functionalities belong inside a properly curated and structured standard library while others should never get beyond the stage of a demonstration repository that people can simply learn (idioms) from - rather than becoming standalone installable packages.
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.
