But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies.
It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies.
Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't.
So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app.
The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.
Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists?
EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.
Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well)
Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud.
We did! This was before docker. we stuck it on mag-tape and DVD, DVD stayed on-site, and the mag-tape went to Iron Mountain. We had escrow agreements with our customers (Chase, Citi, Amex, HSBC, Deutche, etc.) that if we went tits up, they would get a copy of the code with the docs.
The thing that made it work, though, was the fire-drills. Once a quarter (at the beginning, later it was once a year), we would go buy about 10 servers from dell and set them up in the common-room and say to the employees. "We just got hit by a meteor last night. Get us up from off-sites, including all company documentation. Re-inflate the company in 4 hours. Start Now".
Of course we all failed (sometimes the backups didn't even work!), but we got to the point where we could re-inflate the company in four hours. I was so proud of those people.
But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies.
While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package...