Deploying a JS application: 120 seconds.
Do people who have experience with modern JS notice a similar trend, or is it only my project?
@afilina I realize this is probably not helping with your question but I wonder anyway: WHY do you *deploy* using composer or npm?
Shouldn't that be used for, well, managing dependencies? So by the time you want to deploy the stuff it's either already there or only copied based on an already resolved set of dependencies from local cache and then turned into a build artifact?
What am I missing? Is that just nitpicking on choice of words?
@afilina That makes a lot more sense than what I originally understood :)
Sorry, can't be of much help with npm I'm afraid. Not sure if it's an option for you, but maybe using Yarn instead of NPM speeds things up for you? As far as I remember you could even fail the build if an install would alter the locked state with yarn..
@theseer @afilina Modern versions of npm basically fix the issues that yarn was trying to correct, including both performance and state.
It can still be far slower than composer; I know that installing deps for my CSS toolchain takes something like 2x or 3x the time of installing my PHP app deps. From what I can tell, it's a combination of the sheer NUMBER of deps getting installed, and the crazy dep graph it builds (as it nests). π
@mwop @afilina Speaking of CSS: It's crazy how things can turn bigger for no aparent reason.
For instance, I use sass for my CSS stuff, and I used to rely on their C implementation (sassc + libsass) which, after compilation, is a 24k (!!) binary and a ~2MB libsass.so.
Sadly, it got deprecated.
The NPM install is roughly doubled in size: ~6MB.
The recommended standalone installation - a single binary including the dart vm - already eats ~9 MB. But at least it's a single file and no deps.