Repository navigation
chore(mobile): upgrade to Expo SDK 57 - #8609
Merged
Merged
MacroscopeApp / Macroscope - Correctness Check
succeeded
Aug 29, 2026 in 2m 9s
No issues identified (10 code objects reviewed).
• Merge Base:
4669eab
• Head:1e2b733
Details
| ✅ | File Path | Comments Posted | Reason |
|---|---|---|---|
| ➖ | patches/react-native-gesture-handler@2.32.0.patch |
No code objects identified | |
| ✅ | pnpm-workspace.yaml |
0 | |
| ➖ | apps/mobile/package.json |
Excluded by default ignore patterns | |
| ✅ | patches/@expo__metro-config@57.0.12.patch |
0 | |
| ✅ | patches/react-native-screens@4.26.2.patch |
0 | |
| ➖ | pnpm-lock.yaml |
Excluded by default ignore patterns |
Filtered Issues Details
patches/react-native-screens@4.26.2.patch
- line 1163:
headerCenterBarButtonItemsis passed toprepareHeaderBarButtonItemsas'right', even though generated button IDs are${index}-${side}. A center button at the same index as a right button therefore emits the right button's ID, and the combined handler finds the right item first and runs itsonPress;headerToolbarItemshas the identical collision. [ Already posted ] - line 1163:
headerCenterBarButtonItemsis prepared with the same'right'namespace asheaderRightBarButtonItems.prepareMenuderives menu IDs solely from the item index and side, so a menu at index 0 in both arrays receives the same ID; the press handler searches right items first and invokes the right-menu callback when the center-menu action is selected (the same collision occurs withheaderToolbarItems). [ Already posted ] - line 1602:
headerCenterBarButtonItemsis prepared with the same'right'namespace asheaderRightBarButtonItems. Menu leaf IDs are derived from the item index and side, so a right-bar menu and a center-bar menu at the same index both emit IDs such as0-0-right;onPressHeaderBarButtonMenuItemscans the right items first and invokes that menu's action even when the user selected the center menu item. Toolbar menus have the same collision. [ Already posted ] - line 1660:
onSearchTextChangeis only reached when native emits a syntheticbuttonIdprefixed bysearchTextChangeId. The new native toolbar emits that event solely for its fallbackUISearchTextField; when the documented attachedSearchBarsuppliesnavitem.searchController, it embedssearchBar.searchTextFieldwithout registering an editing-changed action. Consequently amailSearchToolbarconfigured with a normalSearchBar,searchTextChangeId, andonSearchTextChangerenders but never notifies JavaScript as the user types. [ Already posted ]
Loading