09:25
<ljharb>
And of course code splitting and tree shaking are both ESM native solutions in the same space. I’m a fan of linear progressive bundles: where the bundle has disjoint sub-bundles from a sequence of entrypoints.
treeshaking works just fine for CJS as well - identically well as for ESM - but the only implementation I’m aware of is for browserify; the others haven’t bothered.
09:28
<naugtur>
treeshaking works just fine for CJS as well - identically well as for ESM - but the only implementation I’m aware of is for browserify; the others haven’t bothered.
We tried to use it at MetaMask and it was not effective. @kumavis started one with a different approach to eliminating unused exports.
09:29
<ljharb>
that’s good to know; I’m still not convinced tho since none of the bundlers have seemingly tried.
09:29
<naugtur>
For now there's no cjs treeshaking we could get to work and provide noticable results
09:29
<ljharb>
to be fair ESM treeshaking doesn’t work that well either
09:29
<ljharb>
at Coinbase, we banned re-exporting in favor of deep importing and the RN app’s size dropped like 20% instantly
09:30
<ljharb>
so i still think the best approach is always “only importing what you need in the first place”, and then you don’t need the crutch of treeshaking at all :-)
09:34
<naugtur>
Own code is less of an issue. Libraries tend to bundle a bunch of related functionality where you only need a small subset (esp. tools like cryptography libs or lodash). These are treeshakeable but a lot of work goes into correctly detecting unreachable code
09:36
<naugtur>
And that's what failed with browserify treeshaking. It disconnects unused export and then leaves deleting code to minification step.
09:37
<naugtur>
Meanwhile the way cjs exports tend to be defined they're reachable from module scope and therefore never eliminated by dead code elimination
09:37
<naugtur>
I doubt it's possible to address with anything we do here though.
12:22
<Jack Works>
<del>we don't use minifier in our production because it is delivered by zip file, and we want better debugibility</del>
12:45
<Jack Works>
Own code is less of an issue. Libraries tend to bundle a bunch of related functionality where you only need a small subset (esp. tools like cryptography libs or lodash). These are treeshakeable but a lot of work goes into correctly detecting unreachable code
Some code bundles outdated polyfills (especially regenerator-runtime), that bring a lot of problems when we want to adopt SES lockdown
14:57
<naugtur>
This is headed off topic real fast, but maybe we could put noop setters on existing fields we want to protect