243 MB?! If that's all code (which is unlikely, sure) and it has an average line length of 100, that's 2.4 MILLION lines! Do you really need that, (no), or have you just 'stockholm syndrome'-d yourself into believing this is not a problem?
I just tried running WinDirStat on the `node_modules` folder in a Create-React-App project I had lying around. Total size was 234 MB. Of that, 129MB was JS files. By far the biggest piece was TypeScript, which has 45MB of .js in 6 files making up its parsing and IDE language service implementation.
Or, take Redux Toolkit, which I maintain. If you look at https://unpkg.com/browse/@reduxjs/toolkit@1.6.2/ , the published package for our current version, it adds up to about 10MB on disk. But, that's because we ship three separate entry points (RTK core, RTK Query UI-agnostic core, RTK Query with React-specific additions), and for each entry point we compile the code to multiple file formats (CommonJS, ESM legacy, ESM modern, ESM with "dev" and "prod" already built in, UMD dev, UMD production), and each of those has sourcemaps. The actual amount of code that ends up in your bundle is about 20KB min+gz.
So, it's a combination of many things: TS itself is big, libraries typically publish packages containing both the original source code plus multiple build artifacts to run in different environments, and packages also include various metadata and other files as well.
I'm not saying this is necessarily a _good_ situation :) Goodness knows that JS dependency trees _should_ be much smaller. But there's a lot more nuance to it than just "245MB of code wut lol".
There's definitely an anchoring effect going on. I remember when dart came out and people were like "lol 100kb hello world, wtf" and now people say "4mb app is reasonable" and nobody bats an eyelid.
Heh, that's actually part of the point I'm making - big difference between "size of build dependencies unzipped and extracted on disk", vs "size of actual app bundle".
