feat: experimental tree shaking support

[bacarybruno]

Summary

Note

Sharing this draft early to get initial feedback and iterate.

Early benchmarking is promising:

• Baseline: 12,983,961 bytes 115s
• Tree-shake: 11,939,372 bytes, 107s
• Delta: -1,044,589 bytes (-8.05%), time -8s
  Validation so far is based on repeated bundle runs (tree-shake off vs on).

Minimal metro config:

const useTreeShake = process.env.METRO_TREE_SHAKE === '1'

const config = {
  ...(useTreeShake
    ? {transformerPath: require.resolve('metro-transform-worker')}
    : {}),
  transformer: {
    unstable_treeShake: useTreeShake,
  },
}

Todo:

• Add unstable_treeShake flag
• sideEffects support
• Bench before / after
• Manual tests
• Run broader before/after benchmarks (multiple apps/configs)
• Ensure no regression when unstable_treeShake is disabled / not set
• Documentation

Test plan

Related issues:

• Tree Shaking Support #1561
• Add Tree Shaking on Production build #132
• Tree shaking while bundling #227

The implementation plan can change depending on react-native-community/discussions-and-proposals#949

[bacarybruno]

Open question: where should tree shaking live?

Expo has its own experimental tree shaking as a serializer plugin. It also has constraints that make adopting Metro-core tree shaking non-trivial: custom transformerPath, bypasses Server.build() entirely via _bundleDirectAsync, and relies on its own serializer pipeline.

Should tree shaking live in Metro core as the source of truth with Expo eventually delegating to it, or should Metro close the door and fully delegate to Expo's implem?

[kitten]

@bacarybruno: re

Should tree shaking live in Metro core as the source of truth with Expo eventually delegating to it, or should Metro close the door and fully delegate to Expo's implem?

We don't currently intend to designate the current, experimental tree-shaking implementation in Expo's core to be stable. It's a proof of concept, and transferring the AST from the transformer to the serialiser, while being the path of least resistance, isn't what we intend to do.

If Metro ships an implementation upstream, we're happy to adopt it and/or tweak as needed to fit it to the existing expectations we need it to comply to.

The main assumption we had was that it'd be nice if a single transformer worker pass could instead operate on source ranges. However, this is potentially a larger change in how our serializers work, but it's one idea we've seen that looks promising. The long and short of it is that we assume we want to keep the serializer lean even with tree-shaking, prevent uncacheable work, and stop transferring ASTs for tree-shaking to work.