Conversation
…#43389) # Why When running the `GitHub-inspect` tool, we would like to take advantage of Unblocked's knowledge about our internal systems. # How Added support for running Unblocked analysis. # Test Plan Run `et gitHub-inspect` <img width="883" height="369" alt="image" src="https://github.com/user-attachments/assets/da71497f-60c4-48c8-aaa0-de8cef7e750b" /> <img width="826" height="252" alt="image" src="https://github.com/user-attachments/assets/611c8020-6ff0-42a1-bc7c-17bf29066c53" /> <img width="875" height="524" alt="image" src="https://github.com/user-attachments/assets/c95dd759-0ed7-4c94-ab15-1979f42873a8" />
…veAdapter (#43390) Co-authored-by: Brent Vatne <brentvatne@gmail.com>
…3255) Co-authored-by: Aman Mittal <amandeepmittal@live.com>
…her (#43395) # Why As spotted and reported in DMs, `picomatch` doesn't perform `matchBase` the same way `minimatch` does and the basename pattern must be implemented differently to match `minimatch`'s (quirkier) behaviour. # How - Update tests and add manual basename matching # Test Plan - Unit test added to cover this scenario # 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)
…ssages (#43329) # Why The first `require` call's errors were being swallowed, and the resulting error that happens after isn't helpful. When `require` succeeds, we should just issue its error and annotate it. This PR restores the old transform behaviour for `.js` and `.ts` files, but with Babel instead to transform ESM to CJS, allowing dual-ESM-CJS in a single file. The same is done for TypeScript but with TypeScript itself instead, relying on the `typescript` package. This is done until we can figure out a better migration path, or tell people to rely on Node's native behaviour instead. This behaviour is activated either when `evalModule` is invoked without a new format argument (which is `null` for the native behaviour) or when `loadModuleSync` is invoked. This covers both the callsite from `@expo/config` and `expo-modules-autolinking` sufficiently. The result of this evaluation is cached in `loadModuleSync` but not in `evalModule`, since the latter is an explicit call to evaluate. The "legacy" behaviour basically allows: - Importing CommonJS modules with ESM, without interop behaviour that'd turn the CommonJS namespace into the default export - Using mixed CommonJS and ESM This only applies to `.js` and `.ts` since `.c[tj]s` and `.m[tj]s` support is new, and won't need the old behaviour. This explicitly circumvents the `package.json:type` field as we did before. It also does not apply to `loadModule`, which is asynchronous, unless loading of `.js` fails, or native TypeScript loading fails. (Internal note; See Slack thread for context: https://exponent-internal.slack.com/archives/C5ERY0TAR/p1771677581725529?thread_ts=1771623609.577789&cid=C5ERY0TAR) # How - Fix swallowed error after `require` - Add ESM-to-CJS transformer with Babel for `commonjs` formats (instead of Sucrase, but matching options) - Switch unknown formats to `commonjs` (js is commonjs, ts is typescript-commonjs now) - Reuse cached, evaluated module on `loadModuleSync` call # Test Plan - Create a test `app.config.js` that contains `import { boolish } from 'getenv'`. Rename to `.mjs` to resolve. - Create a test `app.config.js` that contains `require`. Rename to `.cjs` to resolve. - Repeat the same for `.ts` # 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 Follows-up on: #43013 # How - Add event for env and nodeEnv - Add event for start implementation (Metro) - Add event for config/instantiation (Metro) - Reduce output further when logs+headless are enabled # Test Plan - quick tests with `LOG_EVENTS=1 EXPO_UNSTABLE_HEADLESS=1 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)
…ndencies (#43394) # Why Reverts part of #43379 # 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)
…ions were already granted (#43378) # Why Fixes an issue on iOS where `requestPermissionsAsync` would not forward new authorization options to the operating system when notification permissions were previously granted. This prevented users from requesting additional notification permissions (like alerts, badges, or sounds) after the initial permission grant. closes #20086, closes #20072 # How Changed the implementation to call `requestAuthorizationOptions` directly instead of going through the general permissions system. A previous attempt (#20086) was rejected because expo go's permission scoping. However, I noticed that notification permissions on expo go are not scoped because some 7 years ago they were "temporarily" excluded from scoping. So question is, do we want to handle this in a smarter way or have the exclusion be permanent? # Test Plan - notification tester app <details> <summary>Details</summary> ``` /** * Manual test for #20072 * Verifies that requestPermissionsAsync forwards new options to the OS * even when notifications are already granted. * * Steps to verify the fix: * 1. Press "Request: alert only" → grants notifications with alert * 2. Press "Get permissions" → note allowsSound is false * 3. Press "Request: alert + sound" → should update options * 4. Press "Get permissions" → allowsSound should now be true * * Before the fix, step 3 would short-circuit and step 4 would still show allowsSound: false. */ function PermissionOptionsTest() { const [result, setResult] = useState<string>(''); if (Platform.OS !== 'ios') { return null; } return ( <> <HeadingText>Permission options test (#20072)</HeadingText> <Button title="1. Request: alert only" onPress={async () => { const res = await ExpoNotifications.requestPermissionsAsync({ ios: { allowAlert: true, allowSound: false, allowBadge: false }, }); setResult(JSON.stringify(res, null, 2)); }} /> <Button title="2. Request: alert + sound" onPress={async () => { const res = await ExpoNotifications.requestPermissionsAsync({ ios: { allowAlert: true, allowSound: true, allowBadge: true }, }); setResult(JSON.stringify(res, null, 2)); }} /> <Button title="Get permissions" onPress={async () => { const res = await ExpoNotifications.getPermissionsAsync(); setResult(JSON.stringify(res, null, 2)); }} /> <Text selectable style={{ fontFamily: Platform.select({ ios: 'Menlo', default: 'monospace' }), fontSize: 11, }}> {result} </Text> </> ); } ``` </details> # 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) --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com> Co-authored-by: Tomasz Sapeta <tsapeta@expo.dev>
…#43386) # Why When loading expo-modules.config.json files, we don't have a guard for wrong configurations. # How Added unit tests to check problem, and wrapped loading in try..catch with clear warnings. # Test Plan Test in BareExpo # Checklist - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
# Why We should align the ci-status command with the gitHub-inspect command and make it smaller and faster. # How Rewrite the static et ci-status command as an interactive TUI dashboard, renamed to et ci-inspect (aliases: ci), matching the UX patterns established in et github-inspect. - Interactive category-based navigation (Broken Workflows, Needs Attention, High Volume Issues, All Workflows) with arrow keys, Enter to drill down, Esc to go back - Detail view per workflow with daily trend bar charts, failed run history, and inline log inspection - RECOMMENDED badge on the highest-priority actionable category - Parallel data fetching for GitHub Actions and EAS workflows with ora spinner - Real EAS log fetching in the detail view via eas workflow:view + eas workflow:logs (replaces the old stub message) - Fixed success rate calculation to exclude in-progress/queued runs from the denominator - "Needs Attention" category now requires at least one actual failure - Removed the --inspect CLI flag — the TUI detail view now covers the same functionality inline - Auth warnings only shown when a service is not authenticated # Test Plan - Run et ci-inspect and verify interactive navigation through categories, workflow lists, and detail views - Run et ci-inspect -w last to verify week selection still works - Run et ci-inspect -b <branch> to verify branch option - Verify (f) toggles failed runs in detail view - Verify (l) downloads and displays error logs for both GitHub Actions and EAS workflows - Verify r reloads data from the workflow list - Verify Esc navigates back through each level <img width="708" height="307" alt="image" src="https://github.com/user-attachments/assets/d5d8c6c1-df3c-42e7-ae28-94f6fef0bee1" /> <img width="705" height="235" alt="image" src="https://github.com/user-attachments/assets/cf44ae85-c059-4010-8bbf-a2504e44cd51" /> <img width="490" height="316" alt="image" src="https://github.com/user-attachments/assets/18e6c2e3-0833-41c1-b571-d7a5e9915e0f" /> <img width="832" height="494" alt="image" src="https://github.com/user-attachments/assets/dab01f9f-83a0-4ea8-8712-cc0b0a43fe08" /> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
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 : )