[DOC-1435] Investigate bundle size on type imports with Bun about scalar HOT 10 OPEN

i saw it specifically for bun, but im not entirely sure since it was apparent in the ElysiaJS integration :)

from scalar.

TIL barrel files are bad
https://dev.to/thepassle/barrel-files-a-case-study-o5p

from scalar.

haha no no I don't think barrels are going anywhere. Just that import type thing so the whole module doesn't get imported when you just want types doesn't hurt 😄

from scalar.

Are you saying there is a difference between NodeJS and bun in that regard?

from scalar.

Sounds like a problem with bun? Other bundlers definitely do not include type-only imports...

from scalar.

Maybe related
https://twitter.com/gregberge_/status/1760341181396111843

from scalar.

@amritk is that still an issue? I think you fixed it, did you?

from scalar.

What I thought barrels are recommended? What are you doing to me hanssssss. Good article though something we can definitely improve on 👍🏾. I always thought the bundler would treeshake out everything you don't use. Something to think about for sure.

Yea I think this is on the import side not on the references side, though we could reduce our package use at some point.

Also I did not know about that you HAVE to import type {} I will add that eslint rule 🖖🏾

We should setup some tests to see whats going on

from scalar.

@amritk It's useful to actually read the article 🙃

For our local development environment, and also for running our unit tests, we don't bundle; we use buildless development, and we get a lot of benefits from this approach.

always thought the bundler would treeshake out everything you don't use.

Yes. That is what happens. In production.

In development, eg. Vite does something slightly different: It does not treeshake, but it pre-bundles external dependencies into one file.
This still causes absolutely all JS code to be loaded when using barrel files, but since it's one file and browsers can just parse (but not necessarily execute) hundreds of megabytes of JS per second (on dev machines), it's not a huge issue.

The author seems to be using the most barebone development environment possible, which yeah, does not work well with hundred-module barrel graphs.

Though as a solution, I would rather suggest the author should start using tools actually meant for large production-grade software. The barrel file ship has already sailed.

from scalar.

Yeah, that’s what I thought, too. Tree-shaking is hard though and I’ve had too many cases where tree shaking didn’t work as expected, so definitely something worth to keep an eye on.

That said, before replacing any barrel files we should have a proof that we’re actually improving something. 😅

from scalar.