Bundle native builds with Re.Pack + OXC transform pipeline

[elirangoshen]

Explanation of Change

This PR switches native (iOS/Android) JS bundling from Metro to Re.Pack (Rspack-based), with a Rust transform pipeline (OXC + SWC) for app source and almost all of node_modules.

What changed

• Native builds now bundle via Re.Pack: rock builds go through pluginRepack (rock.config.mjs), with the bundler config at config/repack/rspack.config.mjs and a root rspack.config.mjs re-export.
• App source and all node_modules outside a small allowlist are transformed by the same Rust pipeline: oxc-transform (React Compiler disabled for third-party code; Fast Refresh injection disabled for node_modules, since Re.Pack's refresh runtime does not wrap them), then worklets-loader (Reanimated worklets text-sniff), then cjs-inline-requires-loader (SWC CJS lowering + Metro-style inlined requires). All loaders run with parallel: true worker pools.
• A BABEL_PACKAGES allowlist (~23 packages) stays on Re.Pack's babel-swc-loader with hermes-parser: Flow-typed React Native core packages, packages that call codegenNativeComponent in shipped JS (they need the RN Babel preset's codegen plugin to register Fabric view configs), and @callstack/repack's own runtime.
• cjs-inline-requires-loader gained two options:
  • sourcemap: false: prebuilt packages ship multi-source maps that @jridgewell/remapping cannot compose.
  • hermesLowering: true: adds transform-async-to-generator + transform-async-generator-functions, because Hermes cannot parse async generators. The full RN-preset lowering set was measured and rejected as pure size bloat.
• Merged latest main (React Native 0.86, oxc-transform-react 0.145).

Why

Re.Pack previously ran hermes-parser on every .js file. That parser is pathological on prebuilt, minified single-line files: 95s for one 0.5MB file vs 0.1s with @babel/parser. Metro never pays this cost because its hermesParser option defaults to false.

Results (same machine, same day; cold = cache wiped):

Metric	Metro	Re.Pack + OXC	Delta
Prod bundle, cold	88–94s	54s	~1.7x faster
Prod bundle, warm	11s	2.0s	~5.5x faster
Dev server cold (single platform)	63s	47s	~25% faster
Dev server warm	8s	4s	~50% faster
Minified JS size	38.12MB	35.73MB	−6.3%
Hermes bytecode size	45.15MB	46.75MB	+3.5%

Hermes bytecode grew 3.5%. The likely cause is duplicated import wrappers from the inline-requires step; a contained loader fix is tracked as a follow-up, and staging ManualAppStartup telemetry will show whether it affects startup.

Known follow-ups

• Switch the Babel lane's parser to @babel/parser to match Metro's default.
• CI guard script that re-scans packages for codegenNativeComponent / Flow syntax on dependency bumps, so the BABEL_PACKAGES allowlist can't silently go stale.
• Upstream issues: hermes-parser pathological parse time on minified single-line files; OXC Flow support.

Fixed Issues

$ N/A (internal build-infrastructure improvement; no public GitHub issue tracks this work)
PROPOSAL: N/A (build tooling change, not a contributor proposal)

Automated Tests

No new automated tests: this PR changes the native bundling pipeline only, not runtime app code. Existing CI (typecheck, lint, Jest) covers the unchanged sources; the bundle itself is verified by building and booting each platform (see Tests).

Tests

1. Build and boot each native target, sign in, and exercise core flows:
   • iOS standalone simulator build ("New Expensify Dev" scheme)
   • Android emulator (Pixel 9 Pro, developmentDebug)
   • HybridApp simulator build (built with the callstack-repack pod; verify the ScriptManager TurboModule loads on the hybrid RN host)
2. In each build, verify sign-in completes, the LHN loads, a report opens, and chat messages render and send.
3. Verify React Native DevTools works end-to-end: console evaluation into live Hermes, Sources panel with working breakpoints and scope panes, React Components tree (React Compiler Memo badges visible).
4. Verify Fast Refresh: edit a component and confirm the change applies in ~1s without a full reload; edits to non-component modules require a manual reload (Metro parity). Verify the dev menu and LogBox behave as before.
5. Verify the production bundle compiles cleanly with hermesc -O (bytecode builds without errors).

• Verify that no errors appear in the JS console

Offline tests

Bundling change only; no runtime network behavior is affected. Launch the app once online, then relaunch offline and verify it boots from the bundled JS and renders cached data normally.

QA Steps

Same as Tests (steps 1–2): build and boot each native platform, sign in, verify the LHN loads, open a report, and send a chat message.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

; web builds still use Rsbuild and are unchanged.

[github-actions]

⚠️ This PR is possibly changing native code and/or updating libraries, it may cause problems with HybridApp. Please check if any patch updates are required in the HybridApp repo and run an AdHoc build to verify that HybridApp will not break. Ask Contributor Plus for help if you are not sure how to handle this. ⚠️

[elirangoshen]

This is why the CI script in the post merge pr is crucial - because when there will be deps or new packages that meet those conditions in the comment and won't added to this allowlist if will crush on boot

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...pStyleUtils/computeHorizontalShift/index.native.ts	15.38% <ø> (ø)
... and 13 files with indirect coverage changes