node_modules/babel node_modules/babel-core node_modules/babel-eslint node_modules/babel-plugin-array-includes node_modules/babel-plugin-transform-runtime node_modules/babel-preset-node5 node_modules/babel-register node_modules/babel-runtime
Of course you can just pretend I'm lying.
> or example, updating a minor version of babel generated an 800,000-line commit that was difficult to land and triggered lint rules for invalid utf8 byte sequences, windows line endings, non png-crushed images, and more. Merging changes to node_modules would often take engineers an entire day.
I just did a fresh install in a new directory and ended up with 114M worth of dependencies, so I'm not entirely sure what the difference is.
My point is. 50MB, 114MB, or 500MB worth of javascript dependencies is a massive footprint. It works and I'm relatively happy with what it does, but I don't see this as a stable, long term thing.
mkdir babel-size-check
cd babel-size-check
babel-size-check yarn init -y
yarn init v0.16.0
warning The yes flag has been set. This will automatically answer yes to all questions which may have security implications.
success Saved package.json
Done in 0.05s.
babel-size-check yarn add babel babel-core babel-eslint babel-plugin-array-includes babel-plugin-transform-runtime babel-preset-node5 babel-register babel-runtime
yarn add v0.16.0
info No lockfile found.
[1/4] Resolving packages...
warning babel@6.5.2: Babel's CLI commands have been moved from the babel package to the babel-cli package
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 80 new dependencies.
...
Done in 1.94s.
babel-size-check du -ch -d1
17M ./node_modules
17M .
17M total