Conversation
…p.config.{cts,mts,cjs,mjs}` (#43242)
# Why
When evaluating `.ts` (not `.mts` or `.cts` files) we should allow the
file to be written in "pure" CommonJS syntax. Previously, TypeScript
would force `export {}` to be added, preventing this, and hence causing
Node.js to not be able to auto-detect the file as CommonJS.
Additionally, for backwards-compatibility we should allow `.cts` files
so import and CJS syntax can still be mixed, as before.
# How
- Update options passed to TypeScript `transpileModule` for `.ts` files
to allow CommonJS syntax
- Discover dynamic app configs at `app.config.{ts,mts,cts,mjs,cjs,js}`
# Test Plan
- Rewrite an `app.config.ts` to only use `module.exports` and type-only
imports; this should work
# 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 During development and for both SSG and SSR exports, loaders are bundled using the `isLoader: true` caller option, and are completely isolated from the main/server bundle. However, SSR bundles still included `loader` exports, as previously the SSG codepath still expected them to be in the server bundle when exporting. # How Removed an early return in the loaders' Babel plugin that skipped loader stripping for server bundles. # Test Plan - CI # 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). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…xpo tutorial (#43241) # Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> Follow-up #43190 The `expo-image` library is already included in default tempalte which is used for the Expo tutorial. The installatio instruction and context about `npx expo install` should move to the next chapter. # How <!-- How did you build this feature or fix this bug and why? --> - Remove the `expo-image` install instruction, `<Terminal>` block, npx expo install explanation, and the tip callout from Build a screen chapter. Replace with a sentence noting that the library is already included in the default template. - Add the `npx expo install` explanation and the dev server tip callout to Image Picker chapter, right after the install command. # 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. --> <img width="2466" height="610" alt="CleanShot 2026-02-18 at 21 38 25@2x" src="https://github.com/user-attachments/assets/3a0094c2-d0db-493e-99cc-e40199105034" /> <img width="2538" height="876" alt="CleanShot 2026-02-18 at 21 38 20@2x" src="https://github.com/user-attachments/assets/07d845b6-cfc6-462b-9da4-10398f8ee39b" /> # 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). - [x] 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. --> Fix ENG-19540 # How <!-- How did you build this feature or fix this bug and why? --> - Add an info callout to the Quick Start section of 6 EAS introduction/overview pages linking to the EAS CLI installation section: build/introduction, submit/introduction, eas-update/introduction, eas/metadata/index, eas/hosting/introduction, eas/workflows/introduction. - Revert `npx eas-cli@latest workflow:run` to `eas workflow:run` on the EAS Workflows introduction page for consistency with the link-based approach. - Add `cmdCopy` prop to the multi-command `<Terminal>` on the EAS Update introduction page so the copy button produces a runnable command. # 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. --> Visit each of the 6 modified pages in local dev (`yarn run dev`) and confirm the info callout renders correctly under the Quick Start heading with a working link to /eas/cli/#installation. # 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)
) # Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> Fix ENG-17363 As pointed out in the original task, the "Production errors" section in the runtime issues page mixed two concerns: viewing native logs (a general debugging technique) and handling production crashes (a specific scenario). This made the native log instructions harder to find for developers who weren't specifically debugging production issues. The section also lacked actionable steps for production crashes, instead of spreading relevant guidance (crash reporting dashboards, production mode testing) across disconnected paragraphs. (A problem identified while going through the doc myself, not part of the OG issue). # How <!-- How did you build this feature or fix this bug and why? --> - Extract native log instructions (`adb logcat` and Console app) into a new "Viewing native logs" section placed before so they're discoverable as a general debugging tool, not just a production crash technique. - Rewrite "Production app is crashing" as a concise checklist of actionable steps: check platform crash reports, use native log tools (linking back to the new section), try production mode locally, and check crash reporting dashboards (Sentry, BugSnag). - Add an info callout near the top of the page linking to [Debugging tools](/debugging/tools/) for readers already familiar with React Native debugging. - Minor copy improvements: clarify video title ("ADB Logcat" instead of just "Logcat"), fix "macOS" casing, improve alt text for the Console screenshot. # 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. --> Visit the preview link, https://pr-43208.expo-docs.pages.dev/debugging/runtime-issues/, and manually verify: - The new "Viewing native logs" section renders correctly with the video embed, Terminal component, and Step components. - The "Production errors" section flows logically and links to the native logs section via the anchor `#viewing-native-logs`. - All existing links (Google Play Console, Crashes Organizer, Apple docs, Sentry, BugSnag, WebADB) resolve correctly. # 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). - [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: Kadi Kraman <kadi@expo.io>
# Why Based on / Supersedes #42249 We should be able to log JSONL events and capture them for debugging. In theory, most places that receive/send events, or that have `debug` calls that are ultimately useful to be surfaced in non-terminal environments or when more output is needed should have event calls. In the future, we may be able to add the `profiler` system to this as well, and be able to fork performance-relevant data (e.g. performance marks and profiler outputs) out of the event system. As a proof of concept, this ports the `MetroTerminalReporter` events to the new system (with new requirements applied) # How **Base Requirements:** - should be able to write to file descriptors (compatible with both unix sockets and files/streams), and to file paths - shouldn't slow down the runtime of the CLI by much more than the cost to stringify JSONL events - should be able to define types ahead of time and collect them in one place Most events we want to capture can be captured rapidly (we shouldn't care too much about how many events we log), and we should keep pre-processing to a minimum to allow the event system to always be active without much overhead. The stream that we're writing with is similar to `FastUtf8Stream` / `SonicBoom` and is non-blocking. Flushing is avoided to keep performance high. - Implement non-blocking `LogStream` - Add `installEventLogger` to entrypoint - protects stdout/stderr when logger is active on one of them) - Add `events('category')` helper to create structured log events - Add logger to `MetroTerminalReporter` to demonstrate usage - Clean up calls in `MetroTerminalReporter` and pass sanitized data to event logger - Add `shouldReduceLogs` helper and disable bundling progress when headless is active and event logger is used - **Drive-by fix:** Rename `projectRoot` variable in `MetroTerminalReporter` to `serverRoot` to reflect its actual path # Test Plan Verify that metro events are logged: - Run `LOG_EVENTS=events.log expo start` and check `events.log` - Run `LOG_EVENTS=1 expo start` and check standard 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 closes #38223 The above issue didn't include full repro steps so here they are: ### Prerequisites - An Expo app with `expo-notifications` and `expo-task-manager` configured - A registered `BACKGROUND_NOTIFICATION_TASK` via `TaskManager.defineTask` and `Notifications.registerTaskAsync` ### Sending push notifications Install `expo-server-sdk`: ```bash mkdir /tmp/expo-push-test && cd /tmp/expo-push-test npm init -y && npm install expo-server-sdk ``` Create `send.mjs`: ```js import { Expo } from "expo-server-sdk"; const expo = new Expo(); const token = "ExponentPushToken[YOUR_TOKEN_HERE]"; const mode = process.argv[2] // data (headless) or regular notification const message = mode === "data" ? { to: token, data: { type: "background_task", timestamp: String(Date.now()) }, _contentAvailable: true } : { to: token, title: "Test", body: `Notification at ${new Date().toLocaleTimeString()}` }; const [chunk] = expo.chunkPushNotifications([message]); console.log(`Sending ${mode} notification...`); const result = await expo.sendPushNotificationsAsync(chunk); console.log("Result:", JSON.stringify(result, null, 2)); ``` ### Reproduction steps 1. **Launch the app** and confirm it's in the foreground 2. **Send a display notification:** 3. **Kill the app** (swipe away from recents) 4. **Tap the notification** from the system tray — the app opens 5. **Wait for the app to fully load** 6. **Send a data-only notification:** ### Expected behavior The `BACKGROUND_NOTIFICATION_TASK` executes and JS receives the notification. ### Actual behavior (before fix) The background task silently fails. All subsequent data-only notifications also fail — the task never runs again until the app is force-stopped and restarted. ### Root cause When tapping the notification in step 4, `handleNotificationResponse` called `runTaskManagerTasks` while the app was still launching. This started a headless React instance that raced with the foreground app. The foreground `TaskManager` got misclassified as headless (via `isStartedByHeadlessLoader`), then wiped by `invalidateAppRecord` — permanently breaking background task execution for the session. # How Only call `runTaskManagerTasks` for non-default notification actions (custom action buttons like "Mark as read"). The default tap (`DEFAULT_ACTION_IDENTIFIER`) always opens the app, so there's no need for headless task execution — the foreground app handles the response via listeners. The fix is in `if (!isAppInForeground() && notificationResponse.actionIdentifier != NotificationResponse.DEFAULT_ACTION_IDENTIFIER)` but I also resolved one older TODO around an awkward use of `WeakHashMap`. # Test Plan - tested on device using the repro steps # 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.
5 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 : )