Based on a previous discussion.
This is a short list of some of what can be done to reduce some of the larger items that increase the overall size of react-scripts. Excluded are smaller, opinionated, or rejected fixes.
acorn are used. 4.0.3 (560 KB), used by espree, 3.3.0 (520 KB), used by acorn-jsx and webpack, and ~2.7.0~ 4.0.8 (560 KB), used by acorn-globals and jsdom.webpack required will require the same version of acorn that espree uses.acorn-jsx to bump their required version of acorn, but there has been no response.acorn-globals requires the same version of acorn that webpack and acorn-jsx require, but jsdom uses an older version.espree to bump their required version of acorn.recursive-readdir required specifically requires "minimatch": "3.0.2", preventing it from deduping with the "minimatch": ">= 3.0.3" in eslint-plugin-import. Which normally wouldn't be that much of a problem, but yarn seems to put [email protected] in the base node_modules folder while placing [email protected] in the node_modules folders of babel-core, eslint-plugin-import, glob, fstream-ignore, multimatch, readdirp, and sane, meaning the same version of a ~30 KB dependency is copied six times over. Fixed with #1560.browserify-zlib](https://github.com/devongovett/browserify-zlib) packages ~110 KB of tests. A PR has been filed.escope](https://github.com/estools/escope) depends on es6-map and es6-weak-map. These two packages, along with their dependants d, es5-ext, es6-iterator, es6-set, and es6-symbol, and event-emitter take up ~560 KB. An issue has been filed on this, but escope does not seem to be actively maintained. It seems eslint escope for the next version, which does not contain the polyfills.istanbul-reports](https://github.com/istanbuljs/istanbul-reports) packages a .nyc_output folder of ~310 KB. A PR has been filed.jsx-ast-utils](https://github.com/evcohen/jsx-ast-utils) packages a yarn.lock of ~110 KB. An issue has been filed.node-notifier currently used by jest required includes a CLI that is not used and depends on a framework that is not used elsewhere in react-scripts. https://github.com/facebook/jest/pull/2718, which is included in [email protected], resolved this.Amazing investigation, thank you.
Another thing that might help would be trying greenkeeper to keep things up to date. There's an issue with babel I am noticing.
react-scripts requires [email protected].babel-core requires babel-register >= 6.16.0. Since the latest is [email protected], it grabs that.[email protected] requires babel-core >= 6.18.0, but we only have [email protected] locally, so it has to grab another copy, [email protected].Assuming this isn't just a program with my machine, I think you can run yarn list babel-core to see this. If not, please correct me.
And I don't know why I'm just now noticing this, but since the version of fbjs that react upon depends on a different major version of core-js than Babel and Friends, that is not deduping properly, either. Once react bumps to at least [email protected], it should save something like 1 to 14 megabytes, depending on how yarn dedupes it. Although I'd imagine that [email protected] would have to come out of alpha first.
Also interesting: apparently installed size is larger with Yarn? https://twitter.com/petrhurtak/status/812356423795568640
I think that's because of how yarn and npm dedupe things. The most obvious example would be with core-js; fbjs requires one version, babel-runtime requires another. Installing npm only leaves two copies of core-js, but yarn seems to install a copy in every directory that requires babel-runtime.
You can see this by going to the babel-generator folder under node_modules; when installed by npm, it should not have a node_modules folder, when installed by yarn, it should have one with .bin, babel-runtime, and core-js.
Can confirm that yarn size is between 20-50% larger and the same % increase in total number of files due to the structure under yarn.
Instead of react-scripts I used react-scripts-ts, node_modules folder was 137MB instead of 561MB
but yarn seems to put [email protected] in the base node_modules folder while placing [email protected] in the node_modules folders of babel-core, eslint-plugin-import, glob, fstream-ignore, multimatch, readdirp, and sane, meaning the same version of a ~30 KB dependency is copied six times over.
https://github.com/yarnpkg/yarn/issues/2306 should help with that, once implemented!
Instead of react-scripts I used react-scripts-ts, node_modules folder was 137MB instead of 561MB
This is likely because you have Yarn installed, and Yarn has a bug.
This will be fixed in next release: https://github.com/facebookincubator/create-react-app/issues/1397
acorn-globals now uses [email protected], as does jsdom. However, I noticed that espree depends on a specific version of acorn ([email protected]), so there are still three versions required.
Somewhat related, I was a bit alarmed at my first run of create-react-app yesterday, when I checked the size of my node_modules folder and found 179,491,959 bytes (556.6 MB on disk) for 110,557 items. 556MB is quite a lot!
I was looking for a light-weight way to get up and running with react, ideally to spin up a handful of hello-world apps locally for running through tutorials, etc. Over half a gig does discourage creating a number of quick little prototypes.
I'm new to the react world though, so perhaps there is a good resource for doing this!
@benjaminapetersen
This is a different issue and caused by Yarn bug: https://github.com/facebookincubator/create-react-app/issues/1397. We'll work around it in 0.9.0.
Indeed it is! Nuked the node_modules directory & reinstalled w/nmp instead of yarn, dropped to 72,495,611 bytes (131.7 MB on disk) for 1,922 items
131MB is a lot easier to swallow than 556MB.
This is why you should be careful adopting new tech 😉
[email protected] has been released, which contains the node-notifier bump. It's also about a megabyte smaller.
You can take a high-level view here: http://pkgsize.com/react-scripts.html
jest, webpack, autoprefixer and eslint are the four largest contributors.
autoprefixer largely due to the ever increasing caniuse-db: http://pkgsize.com/autoprefixer.html (is autoprefixer really a must-have?)
jest mostly due to jest-cli mostly due to jsdom stuff and istanbul-api: http://pkgsize.com/jest-cli.html
... and they all include a whole bunch of babel libs – of which core-js makes up a large part: http://pkgsize.com/babel-runtime.html
I wonder how this compares to master since we switched to webpack 2 and might have new regressions (or it might be better). We should cut a canary release.
FWIW a PR has been filed for browserify-zlib: https://github.com/devongovett/browserify-zlib/pull/22
jest, webpack, autoprefixer and eslint are the four largest contributors.
jest has an issue similar to this one. You might be able to get webpack and eslint interested if you asked.
autoprefixer largely due to the ever increasing caniuse-db: http://pkgsize.com/autoprefixer.html (is autoprefixer really a must-have?)
It's gonna be there anyway, since cssnano depends on it.
I'll close this as stale. (But efforts to further dedupe are welcome!)
Most helpful comment
You can take a high-level view here: http://pkgsize.com/react-scripts.html
jest,webpack,autoprefixerandeslintare the four largest contributors.autoprefixerlargely due to the ever increasingcaniuse-db: http://pkgsize.com/autoprefixer.html (isautoprefixerreally a must-have?)jestmostly due tojest-climostly due tojsdomstuff andistanbul-api: http://pkgsize.com/jest-cli.html... and they all include a whole bunch of
babellibs – of whichcore-jsmakes up a large part: http://pkgsize.com/babel-runtime.html