Agenda 2021-10-19

[afoxman]

Introductions:

• Welcome, Stripe devs!

Checking in on last-month's topics

• Upstreaming hash-based Metro module IDs
• Docs for setting up a metro cache using S3
• Haste-map replacement experiments
• esbuild experiments/progress

Topics

• Different bundle output formats? ESM, Hermes byte code, ...
• Bundle-size reduction using techniques like tree-shaking
• Expo: Metro + Sucrase
• require() cycle detection at runtime - valuable? should it be able to fail bundling?

Open discussion

Wrap-up

[kelset]

One topic I'd like to dive a bit more into is bundle size improvements / treeshaking, to hear what folks have been trying in this space. It was touched a bit last time but I'd like to hear more :3

[kelset]

Another topic I'd like to hear a bit about is the newly announced improvements the Expo team did to Metro via Sucrase:

• https://blog.expo.dev/drastically-faster-bundling-in-react-native-a54f268e0ed1
• https://github.com/alangpierce/sucrase
• https://github.com/expo/expo-cli/tree/master/packages/metro-config

[zamotany]

On the ESBuild expermients/progress:

I've tried using esbuild-loader for Webpack and Re.Pack in a fresh React Native project:

• Using babel-loader on average it took 33s to bundle the code (no persistent caching, 3 attempts measured)
• Using esbuild-loader + babel-loader (for React Native due to Flow) the initial bundling took 35s (cold cache) and then 22s (with hot cache, 3 attempts measured).

Given the fresh project is not a production project, I expect the difference to grow for bigger codebases. This is specific to how esbuild-loader is implemented and the fact that ESBuild's transform API doesn't allow to use plugins, I still had to use babel-loader for React Native. Pre-transpiling React Native with Babel to get rid of Flow is an option, but I don't expect many users to go that route.

[noahsug]

On reducing bundle sizes, here are some of our numbers:

• Tree-shaking: 1.3% / 15 KB reduction in gznipped JS
  • Note: Webpack's tree shaking reduces JS size by 7% / 58 KB, so there's definitely room for improvement
• Bundle splitting: 18% / 200 KB reduction in gznipped JS
  • This 18% is compared to a previous custom bundle splitting algorithm we were using before
  • Our total page weight is now 7% higher than Webpack's
• Hash module IDs: % of sharable bundles between deploys increased from 3% → 95%
  • Page weight was also increased by 3-5%
  • We're running an AB test soon to evaluate this impact

We've started the process of sharing our tree shaking and bundle splitting code, and are excited for others to start using it!

[motiz88]

If there's time: I'm curious to get people's thoughts on require() cycles and the runtime warning we show in development. Have you found this cycle detection useful? Do we need an option to ban cycles more strongly i.e. fail the build when we detect one? This is mostly prompted by facebook/metro#707.

Regarding the runtime warning, I think it's noisy and unactionable in its current form - it's really something that should live in a static analyser / IDE language service, not in the runtime. I'm leaning towards either removing it (making it opt-in?), or scoping it to user code i.e. non-node_modules.

[tido64]

Huh, I didn't realize that Metro had one. We've never seen it internally, I think. We've had many issues related to this in the past so we wrote our own cycle detection plugin: https://github.com/microsoft/rnx-kit/tree/main/packages/metro-plugin-cyclic-dependencies-detector

It's enabled on CI. It ignores everything under node_modules/ though, so maybe that helps with verbosity.

[afoxman]

I've seen runtime cyclic dependency warnings when debugging, but I'm not sure they're from injected metro code in the bundle or from somewhere else like our own runtime (internal to Microsoft).