Conversation
# Why When no paths params were passed to codemod, it showed help without direct cta # How 1. When no path is passed, display no path warning <img width="1039" height="63" alt="Screenshot 2026-05-06 at 10 50 08" src="https://github.com/user-attachments/assets/5b9ba98d-7237-4961-9a55-7b097fc1bbe6" /> 2. When wrong transform is passed and no path is specified, display the wrong transform warning <img width="876" height="34" alt="Screenshot 2026-05-06 at 10 50 28" src="https://github.com/user-attachments/assets/c9a1c166-2fa6-45bd-8ce3-8fa26d84d5c5" /> # Test Plan 1. CI 2. Manual testing # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…on (#45594) # Why Currently, all internal source-map representations take up a huge chunk of memory that's redundant, since they're essentially a `number[][]` tuple-array structure. This makes up the largest possible win in the Expo dev-server's memory usage, if reduced. > [!NOTE] > Marking as 'ready for review', but I might still rewrite and reformat this PR later, so while the implementation and functionality is nailed down, code may still change and be refactored. # How This PR swaps the internal use of source-maps to use [jridgewell's sourcemaps](https://github.com/jridgewell/sourcemaps) instead. As source-maps are used, the internal `Int32Array` representation is used, and when we serialize or store source-maps, they're stored as packed `number[]` arrays. When Metro (legacy code paths) utilise the `map` property, they're repacked into the "usual" in-memory representation instead. **Side-note:** All the added `@jridgewell/*` packages are already in our module graph in an Expo app because of Babel. The codepaths modified in this PR avoid any repacking and only mostly rely on the packed transfers. This is cache incompatible but has little negative effects. Performance is mostly neutral (apart from a net-positive reduction of `.map` requests), but retained memory shrinks by about 20-30% (depends on amount of modules in graph), since every module holds on to a more compact source-map representation than before. # Test Plan - Unit tests amended, manually checked `expo start` and `expo export` - Some tests are still outstanding, - **NOTE:** That's why the branch is marked as an experiment <table> <tr><td> <strong>Heap Summary Before (532MB)</strong> </td><td> <strong>Heap Summary After (348MB)</strong> </td></tr><tr><td> <img width="300" alt="Summary Before" src="https://github.com/user-attachments/assets/521eb2c7-52ab-4e71-839e-0d1bacf6a1d8" /> </td><td> <img width="300" alt="Summary After" src="https://github.com/user-attachments/assets/dbe190c2-930b-4151-a4c9-dce95187dc34" /> </td></tr></table> <table> <tr><td> <strong>Heap Details Before (175MB module mem)</strong> </td><td> <strong>Heap Details After (48MB module mem)</strong> </td></tr><tr><td> <img width="900" alt="Heap Details Before" src="https://github.com/user-attachments/assets/ee1c8c55-e6fb-48c7-9a60-77183c88a687" /> </td><td> <img width="900" alt="Heap Details After" src="https://github.com/user-attachments/assets/3e496027-a584-451d-a245-b068e8c86c7c" /> </td></tr></table> Impact is **-35%** on a typical `expo start` (`apps/router-e2e`) after bundling a web+server build. # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…tcss config caching (#45626) # Why Supersedes #45622 Supersedes #45076 We seemingly can safely upgrade to `postcss@^8.5.14`. We're not affected by the CVE, but this has a few parser performance fixes. We can also take this opportunity to in-memory cache the config and pipeline, and test this during the beta. # How - Upgrade to `postcss@^8.5.14` - Memoize the config and pipeline # Test Plan - CI tests should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…yntax bugs with fix-up transforms (#45601) # Why Resolves #45592 There's three fixes that have landed in Hermes v1 since the `250829098.x.x` branch cut that can reasonably be triggered by user code. In descending order of likelihood: - facebook/hermes@68bfb3a - facebook/hermes@18a963465 - facebook/hermes@1e94fbe0e The first issue is very easy to trigger, since it involves any complex parameters for any async arrow function. These commits have been identified in a full diff between `250829098.0.10` and the `static_h` branch on Hermes, and cross-checked against the `250829098.0.0-stable`. There's more fixes that this branch doesn't contain but they either: - aren't relevant for most codebases or are Hermes toolchain fixes - are runtime fixes (unfortunate, but not relevant for Babel) - cannot be fixed or are hard to hit - **apply only to async generators which are already transpiled by our preset** # How We apply three targeted fix-ups in Babel transforms that are targeted to these fixes. They swap out the problematic patterns with working ones. - Add test cases to `test-suite` for failing patterns - Add `fix-hermes-v1-async-arrow-non-simple-params` plugin for Hermes v1 preset - Add `fix-hermes-v1-class-in-finally` plugin for Hermes v1 preset - Add `fix-hermes-v1-super-in-object-accessor` plugin for Hermes v1 preset # Test Plan - Checked fixes against the `test-suite` and confirmed they avoid all three bugs - Added unit tests per Babel plugin with snapshots - Confirmed that transform performance isn't impacted significantly using `node scripts/profile-plugins.js --config hermes-v1` # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why Reported at facebook/metro#1696. This PR is being upstreamed at: facebook/metro#1711 The intention in Metro is that cross-device paths are represented as relative normal paths. If the root dir is at `C:\project` then a cross-device normal path at `D:\temp` is represented as `..\..\D:\temp`. This assumption is broken in several places, like `normalToAbsolute` printing, leading to `C:\D:\` paths that are invalid. # How - Fix `normalToAbsolute` not cutting off cross-device absolute paths - Fix `resolveSymlinkToNormal` cutting off trailing slash for absolute Windows device paths - Prevent double slash when appending normal path to root `C:\` path - Prevent `TreeFS#remove` from re-normalizing internally built paths, which can lead to excessively clamped paths - Adjust relative root maximum depth for Windows (remove `-1` adjustment for Windows) # Test Plan - Represented in unit test changes - **Note:** Invalid unit tests have been removed for paths that rise above the filesystem root # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build this feature or fix this bug and why? --> # Test Plan 1. Expo Go 2. Router e2e # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…ath` (#45650) # Why The `TreeFS.hierarchicalLookup` code path is exercised quite often by Metro. It's called on each `getPackageForModule` lookup, effectively searching for `./package.json` at each parent hierarchically until the `node_modules` boundary. This is a special case that makes the `TreeFS.#checkCandidateHasSubpath` check trivial, which means it can be sped up. An improvement here (which is about 20%) yields an outsized improvement on resolution performance. # How - Add fast-path to `TreeFS.#checkCandidateHasSubpath` for simple sub-paths # Test Plan - Tests pass unchanged - New tests cover uncovered code paths # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…45641) # Why Fix regression in #45523 Because we use `console.*` methods, and these are buffered, output might be lost if we're logging just before we call `process.exit`. Similarly, other output in our CLI is lost when we're fatally crashing. # How - Add an `on('exit')` handler to `LogRespectingTerminal` that manually flushes - Guard with `isExiting` in `log.ts` that manually writes to `stdout`/`stderr` instead # Test Plan - Manually tested to restore fatal stderr output # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build this feature or fix this bug and why? --> # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…ditch generators (#45651) # Why Stacked on #45650 While it's a larger divergence from upstream, converting the walkers to cleaner methods with no `opts` is a little more maintainable from an isolated perspective and allows us to experiment with more changes faster. Ditching the generators also yields a small performance improvement on the methods that use them only internally. # How - Replace `lookupByNormalPath` with individual walkers with callbacks - Remove double parent directory walk from `addOrModify` - Ditch internal generator methods for `forEach` callbacks # Test Plan - Tests should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
) # Why `expo-updates` would fail to read app.manifest and meta-data tags when consuming it as a brownfield AAR, causing update to not start up properly on android # How Extended `expo-brownfield`'s gradle plugin (`ExpoBrownfieldSetupPlugin`) to forward the host `:app` module's build-time outputs into the published brownfield AAR's release variant. Two pieces are forwarded: 1. **`:app:mergeReleaseAssets` output** is copied into a generated source dir on the `:brownfield` library and registered as a release-variant asset source. Forwarding the *merged* assets output (rather than a specific generator task) is deliberate: it picks up everything AGP would bundle into the host APK's `assets/` — the RN JS bundle, expo-updates' `app.manifest`, expo-constants' `app.config`, and any future generated asset emitted by a host-side gradle plugin. The old `setupBundleDependencyForRelease` and the standalone `generated/assets/react/release` source dir are now subsumed by this. 2. **Every `<application>` `<meta-data>` entry** from `:app/src/main/AndroidManifest.xml` is forwarded into a generated release-variant manifest on the `:brownfield` library, which AGP merges into the consumer's manifest at AAR-consumption time. This covers expo-updates, expo-notifications, expo-dev-launcher, and any other config plugin that injects runtime configuration into the host manifest. The forwarder also resolves `@string/...` references against `:app/src/main/res/values/strings.xml` (inlining e.g. `expo_runtime_version` → `"1.0.0"`) so the AAR doesn't need to also forward `strings.xml`, and preserves `android:resource="..."` refs alongside `android:value="..."`. # Test Plan End-to-end on Android: 1. **Publish the brownfield AAR to Maven Local** ```bash cd apps/minimal-tester npx expo-brownfield build:android --repository MavenLocal --release ``` 2. **Verify the AAR carries the forwarded artifacts** ```bash AAR=~/.m2/repository/com/community/minimaltester/brownfield/1.0.0/brownfield-1.0.0.aar unzip -l "$AAR" | grep -E 'assets/|AndroidManifest' unzip -p "$AAR" AndroidManifest.xml unzip -p "$AAR" assets/app.manifest unzip -p "$AAR" assets/app.config ``` 3. **Run the brownfield consumer against the published AAR** ```bash cd apps/brownfield-tester/isolated/android ./gradlew assembleRelease ``` 4. **Confirm the consumer's merged manifest picked up the forwarded meta-data** ```bash grep -A1 expo.modules.updates \ apps/brownfield-tester/isolated/android/app/build/intermediates/merged_manifests/release/processReleaseManifest/AndroidManifest.xml ``` # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )