Conversation
# Summary Some of these have likely been left over by the bump, or changed accidentally. None of the remaining version pins seem reasonable or necessary to me. The `@expo/log-box` dependencies are curious. `expo-router` has a non-optional peer, but then `expo` has a dependency, but also a transitive one via `@expo/metro-runtime`. We should likely make a peer+dep combo consistent in `@expo/metro-runtime` and `expo-router` until we resolve the circular/dual-use nature of `@expo/log-box`. # 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. --> - [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 The `setIconsAsync` function emits a warning when no icon is defined in the Expo config, but this is a perfectly valid state -- not every project needs a custom icon during development. The warning adds noise without actionable value. # How Removed the `WarningAggregator.addWarningIOS` call that fires when no icon is configured, and removed the corresponding test assertion. # Test Plan Updated the existing test to no longer expect the warning. Existing icon tests continue to pass.
…#45523) # Why Metro's Terminal class manages progress bar status lines on stdout using cursor movement. Two issues caused progress bars to appear as permanent, stuck output: 1. **Stale status snapshots**: Terminal's `#update()` is async and captures `#nextStatusStr` at the start. When `_log()` calls `terminal.log()`, the async update captures whatever status is currently set (often a stale progress bar) before `terminal.status()` can update it. 2. **Stderr cursor corruption**: `console.warn()` and `console.error()` during server bundle evaluation write directly to stderr, which shifts the terminal cursor without Terminal's knowledge. When Terminal tries to clear status lines via cursor movement on stdout, the positions are wrong. # How **Status clearing** (`TerminalReporter.update()`): Clears `terminal.status('')` before `_log()` runs for non-progress events. This way Terminal's async `#update()` captures an empty status and writes no progress bars alongside log lines. The correct status is restored by `terminal.status()` at the end of `update()`. **Non-interactive suppression** (`MetroTerminalReporter._getStatusMessage()`): Returns empty string in non-TTY mode since status lines can't be overwritten and just create noise. "Bundled Xms" completion messages still appear (they use `terminal.log()`). **Stderr coordination** (`LogRespectingTerminal.logStderr()`): Intercepts `console.warn`/`console.error` and routes them through a `logStderr()` method that uses Terminal's public API (`status()` + `flush()`) to clear progress bars before the stderr write and restore them after. # Test Plan - Unit tests for status clearing behavior, non-interactive suppression, and progress event passthrough - Manual testing with `expo start` on a project that triggers server bundle warnings during bundling - Verified with debug logging that all event types flow through the `update()` override
# Why
Node.js emits a `DEP0169` deprecation warning for `url.parse()` during
Metro dev server upgrade handling. The warning recommends using the
WHATWG `URL` API instead.
# How
Replaced the `url.parse(request.url!)` call in `runServer-fork.ts` with
`new URL(request.url!, 'http://localhost')`. Since only `pathname` is
extracted and `request.url` is a relative path, the base URL value is
irrelevant. Also removed the unused `import { parse } from 'url'`.
# Test Plan
Verified the dev server starts without the `DEP0169` deprecation
warning. WebSocket upgrade handling (HMR) continues to work as before
since the pathname extraction behavior is equivalent.
#45516) # Why Web client logs in the Metro terminal have no platform indicator, making it hard to distinguish them from native logs when running multiple platforms simultaneously. API route logs already show a prefix (the lambda symbol), but web client logs are unlabeled. Additionally, React's browser console calls use printf-style format strings (e.g., `console.warn('%s\n\n%s', msg1, msg2)`) which the browser substitutes natively, but when forwarded to Metro's terminal logger the raw `%s` placeholders are printed literally. # How - Changed the web HMR client to send `mode: 'web'` instead of `mode: 'BRIDGE'` with a separate `platform` field. The `mode` field is the only custom field Metro's HmrServer forwards to the reporter event, so encoding the platform there is the only way to pass it through without patching Metro. - Added `getPlatformTagForClientLog()` in `MetroTerminalReporter` that maps known mode values (`web`, `ios`, `android`) to formatted names (`Web`, `iOS`, `Android`) and passes them to `logLikeMetro` as the prefix. - Added `applyConsoleFormatting()` that applies `util.format` to log data when the first item contains printf-style specifiers, matching browser console behavior. - Removed the `$$EXPO_INITIAL_PROPS` guard and redundant setup log messages from `setupHMR.ts`. # Test Plan - Added unit tests for platform prefixing (web, NOBRIDGE, no mode) and format string substitution. - Tested manually with `expo start --web` and verified `Web LOG`, `Web WARN` prefixes appear in the terminal.
# Why The error overlay footer (with reload/dismiss buttons) uses `position: absolute`, which causes it to overlap the code frame content when scrolling. Users can't see the bottom of the code frames because the footer covers them. # How - Changed the footer from `position: absolute` to `position: fixed` so it stays anchored to the viewport bottom regardless of scroll position - Added `3.5rem` bottom padding to the code frames container to prevent content from being hidden behind the fixed footer # Test Plan - Open an app with a runtime error that shows a code frame in the error overlay - Verify the footer stays at the bottom of the screen - Verify the code frame content is fully visible and not obscured by the footer - Verify scrolling behavior works correctly
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.
2 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 : )