Repository navigation
Tree Shaking Support #1561
Description
I’ve ported most of the tree-shaking implementation from esbuild to a Metro (Babel) plugin and have been running it in production for about a year. Since #632 is closed, I’d like to know Metro’s plans for tree shaking. I’m happy to contribute or upstream my work if that would be useful.
https://github.com/xhsfe/thor-x/blob/main/packages/metro-plugin-tree-shaking/DESIGN.md
Activity
robhogan commentedon Aug 19, 2025
Hey @ArrayZoneYour - we're definitely interested in upstreaming any tree shaking implementation that's compatible with Metro's architecture (ie, does as much as of the heavy work as possible within cacheable transforms).
At first look this is super impressive and you've obviously worked out Metro's internals in some depth! There are couple of it looks like we'd need to find solutions for - e.g. the limitation you mention "When tree-shaking is enabled, transform result is not only generated by input file." sounds like a potential problem for keying the transform cache.
I'll find some time this week to look through this more closely and understand the design better and get back to you. If you're not already on the React discord, drop me an email on my github handle at meta.com and I'll send you an invite, might be useful to chat there.
CC @EvanBacon for design thoughts/comparison with Expo tree shaking as well.
ArrayZoneYour commentedon Aug 21, 2025
@robhogan Thanks for your reply. I’ve sent the email and look forward to making further progress on tree shaking 😄.
ArrayZoneYour commentedon Aug 21, 2025
Yes, I create metro server twice currently, The cache can be reuse in prev builds is ModuleGraph & FileCache. Transform cache should be isolated and handle carefully (should involve liveParts info if remote cache enabled ?)
I use environment variable to identify whether the transform is tree shaking enable (like
process.env.PRE_BUILD) then add it to partialKey stableHash args currently.KingAmo commentedon Mar 3, 2026
any update on this?