Conversation
# Why It's hard to debug widgets without access to native logs from different target. # How In debug, create a RedBox view with the error message gathered from JSC execution ## Widgets <img width="300" alt="image" src="https://github.com/user-attachments/assets/c3210b38-fe43-4e53-b817-918e46e97054" /> ## Live Activities <img width="300" alt="image" src="https://github.com/user-attachments/assets/e2d2cef9-2c09-400e-8217-cf8897d81cb1" /> # Test Plan Make invalid widget # Checklist - [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 add missing doc for community bottom sheet # How - [docs] add `@expo/ui/community/bottom-sheet` docs and API data - [ui] fixed regression #44642 for dynamic size bottom sheet --------- Co-authored-by: Aman Mittal <amandeepmittal@live.com>
…s` (#45430) # Summary This is converted to an exact version during pack/publish, not `*`, although it's in `peerDependencies`. We need to move these back to `*` and instead add the `workspace:*` specifier to `devDependencies` # 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)
…terns (#45418) # Why We'd like to block a few native folders from being crawled by `metro-file-map` strategically, to make the common case for app crawling a little faster. These have been picked to be both safe and to make most non-monorepo/simple projects faster to start up. Currently, after a native build the initial crawl slows down since it includes a few native folders that can be quite heavy. However, some of these folders are always safe to exclude, and only weren't excluded since Metro didn't give us a way to exclude project-root-relative folders. These are: - `./ios/Pods/` - `./android/app/build/` - `./android/.gradle/` These should always be safe to ignore since they only get created as part of a native build and have a low chance of being accessed directly in Metro. > [!NOTE] > We also considered allowing these folders to be discovered by the on-demand filesystem. However, this seems redundant as it should always be safe to exclude these folders, and we don't have much use for the "partial" crawl + on-demand access otherwise. We've also defined the previous default `blockList` inefficiently. We should use `exclusionList` for our patterns, since it adds the default and combines it with our patterns. # How - metro-config: Refactor `blockList` default config to only use `exclusionList` - metro-file-map: Reapply `ignore` check to directories' normal paths - metro-config: Add `^` regexes for "ios/Pods", "android/app/build", and "android/.gradle" - **Note:** These will only match and exclude them in the project root - metro-config: Add missing exclusion for `.expo/web/cache` - **Note:** I don't know what else we place here, but we should review the use of this folder and consider a different place for this # Test Plan - Manually tested against `apps/router-e2e` and `apps/bare-expo` - Unit test added for extra `ignore` call # 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 `tools/src/Workspace.ts` shelled out to `yarn workspaces info` to enumerate the monorepo. The post-processing step relied on`getPackageByName`, which assumes a workspace package's directory name matches its `package.json` `name`. That assumption fails for scoped packages like `@expo/ui` (lives at `packages/expo-ui/`) and `@expo/app-integrity` — their `workspacePeerDependencies` came back empty, silently masking peer specs from `updateWorkspaceProjects` during publish. That's why `@expo/ui@56.0.0` shipped to npm with `peerDependencies.expo = "workspace:*"` and broke installs. ## How - Replace `yarn workspaces info` with `pnpm m ls --json --depth=-1` that constructs `WorkspacesInfo` directly from each package's `package.json`. Drops the `getPackageByName` lookup. - Add `mismatchedWorkspacePeerDependencies` to `WorkspaceProjectInfo` (subset of`workspacePeerDependencies` whose declared range doesn't satisfy the local workspace version) and surface it in `et validate-workspace-dependencies` so stale peer pins get caught before they ship. - New unit tests in `Workspace.test.ts` exercising the pure builder against fixture monorepos including the `@expo/ui`\-shaped dir-mismatch case. ## Test plan `et validate-workspace-dependencies` passes `et publish-packages --dry @expo/ui expo` produces a clean dry-run with `peerDependencies.expo` rewritten to the new `expo` version
# Why A recent publish shipped with `workspace:*` strings embedded in several published `package.json`'s . Each shipped because `npm pack` doesn't understand pnpm's workspace protocol and serializes the literal string into the tarball. I patched around it once with a `resolveWorkspaceSpecs` task (reverted) and won't attempt that again. # How `tools/src/Npm.ts`'s shell-outs migrate from `npm` to `pnpm` for the publish-path operations: - `publishPackageAsync:` `pnpm publish`. Adds `--no-git-checks` since we already enforce via `checkRepositoryStatus`. - `packToTarballAsync:` `pnpm pack`resolves `workspace:` specs to concrete versions at pack time. - `addTagAsync` / `removeTagAsync` — `pnpm dist-tag. Added for consistency,`delegates to npm. # Test Plan - `pnpm pack` an expo workspace package locally and confirm the tarball's `package.json` has no `"workspace:` substrings - `pnpm publish --dry-run` runs `prepublishOnly`
# Why Cleanup pass after the main pnpm migration in `Workspace.ts` and `Npm.ts`removing yarn/npm references in tooling and one error message. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How Grepped for and removed remiaing references to yarn/npm <!-- How did you build this feature or fix this bug and why? --> # Test Plan
# Why `"react-native-screens": "~4.25.0-beta.1"` resolves to both beta and all the nightly versions `4.25.0-nightly-*`. Additionally there may be breaking changes between screens beta versions # How Pin the dependency to be exact version. # Test Plan 1. Test in local project **Note**: if user has a different `react-native-screens` version specified in their `package.json`, two versions of screens may be installed. However expo-doctor should detect this problem and display a warning # 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 Documents the TextField worklet/`ObservableState` flow on both platforms. Stacked on top of #45424 so the doc snippets line up with the component changes. # How - **[swift-ui]** Update `textfield.mdx` to cover the worklet-based selection callback and `ObservableState` usage. - **[jetpack-compose]** Update `textfield.mdx` and `usenativestate.mdx` to match the Compose-side API. - Regenerated API schema JSON with `et gdad -p @expo/ui`. # Test Plan Rendered docs locally and verified MDX builds without errors. # Checklist - [ ] 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). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) --------- Co-authored-by: Aman Mittal <amandeepmittal@live.com>
#45431) ## Why When running pod install with `EXPO_USE_PRECOMPILED_MODULES=1` with React Native built from source, a warning about falling back to source build for the Expo Modules is picked up as an error in EAS build logs: ``` [!] [Expo] EXPO_USE_PRECOMPILED_MODULES=1 was set, but React Native is configured to build from source (RCT_USE_PREBUILT_RNCORE is not 1). Precompiled Expo modules require the prebuilt React.xcframework, so every Expo module will be built from source for this install. To use precompiled modules, ensure `ios.buildReactNativeFromSource` is not `true` in the `expo-build-properties` plugin (the default uses the prebuilt framework), or export RCT_USE_PREBUILT_RNCORE=1 before running `pod install`. ``` This looks like the source of the error, but is actually not. ## How This PR fixes this by changing the log from using `Pod::UI.warn` to `Pod::UI.puts`. ## Test-plan ✅ Run builds with `EXPO_USE_PRECOMPILED_MODULES=1` and `buildReactNativeFromSource`. # Checklist - [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) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
# Why Maestro has deprecated `--android-api-level`. Removing the `android_api_level` param from the docs prevents new users from adopting a deprecated option. Also updated the descriptions for other device-related params to reference `maestro list-cloud-devices` instead of `maestro cloud --help`. # How Updated the Maestro Cloud job docs in: - `docs/pages/eas/workflows/pre-packaged-jobs.mdx` - `docs/pages/eas/workflows/syntax.mdx` Changes: - Removed the `android_api_level` param from the YAML example and the parameters table. - Replaced `maestro cloud --help` with `maestro list-cloud-devices` for `device_model` and `device_os`. - Removed the trailing "Run \`maestro cloud --help\`..." sentence from `device_locale` (locale isn't device-specific). # Test Plan Docs-only change; visually verified the updated sections render correctly. # Checklist - [ ] 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). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) Signed-off-by: Ash Wu <hsatac@gmail.com>
## Why Missing external precompiled XCFrameworks are an expected source-build fallback when `EXPO_USE_PRECOMPILED_MODULES=1` is enabled without matching third-party prebuild artifacts. Reporting these as CocoaPods warnings makes successful installs look more concerning than they are. ## How Changed the missing external prebuild message from `Pod::UI.warn` to `Pod::UI.puts`, while keeping the fallback notice and expected tarball path in the logs. ## Test-plan ✅ Run `EXPO_USE_PRECOMPILED_MODULES=1 pod-install` and verify that we see the messages about 3rd party frameworks like Reanimated, RNScreens etc is not found as XCFrameworks. # Checklist - [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) --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
…d deps check grace period (#45417) # Why We're awaiting the `DevelopmentSession` ping call on startup, which isn't strictly necessary, as we're not relying on it being instant as the CLI starts up (all UIs displaying its data don't treat that data as highly accurate, as far as I know) We can also remove the grace period of the two API calls on start up entirely, down to a tick, since that's only relevant for testing. # How - Remove `await` on `DevelopmentSession` and instead run it as a fire-and-forget - Add cancellation for concurrent start/stop on `DevelopmentSession` - Remove 100ms grace period for install check and instead just wait a single tick # Test Plan - CI should pass unchanged / manually tested with `expo start` # 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)
…orce exit (#45445) # Why Supersedes #44837 The current exit guard may still have its own timeout included in the exit guard, and we need to wait a tick for our own timeout to drop. We can then include timeouts in the active resources check, and hence detect spurious timeouts and intervals properly. # How - Remove `Timeout` filter from active resources - Delay next `ensureProcessExitsAfterDelay` check by a tick, so active resources from the same tick (like the handler's own timeout) drop - Reduce default timeout to 4s # Test Plan - Manually verified with `expo export` and a `setInterval` in a Metro config # 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)
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.
11 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 : )