feat(expo): add support for Expo SDK 55 and 56#35904
Open
itsjithinv wants to merge 7 commits into
Open
Conversation
Add full dependency version matrices for Expo SDK 55 and 56 and make SDK 56 the default for newly generated Expo projects. Detection now recognizes majors 53-56, and getExpoDependenciesVersionsToInstall picks the matching version set for the installed SDK (falling back to 56). The winter-runtime Jest configuration (introduced for SDK 54) now applies to SDK 54+ instead of being v54-specific.
Add a migration that surfaces AI upgrade instructions for moving Nx workspaces to Expo SDK 56 (covering React 19.2 / React Native 0.85, the @expo/metro packaging change, Babel/Jest updates, and validation steps).
Expo SDK 55 moved Metro into the @expo/metro package family. @nx/expo was installing the standalone metro-config/metro-resolver packages and merging / resolving through them, which pulls in a second, incompatible Metro instance and breaks bundling (TypeError: Cannot read properties of undefined reading 'transformFile'). - withNxMetro and the Nx resolver now prefer @expo/metro/metro-config and @expo/metro/metro-resolver, falling back to the standalone packages for SDK 53/54. - withNxMetro no longer overrides Metro's projectRoot to the workspace root on SDK 55+. Expo's babel transformer resolves the project's .babelrc.js relative to projectRoot, so forcing the workspace root caused 'Cannot find module .babelrc.js'. Workspace libraries are still resolved via watchFolders, nodeModulesPaths and the custom resolveRequest. - New SDK 55+ apps no longer install the standalone metro-config/metro-resolver packages nor @expo/metro-config directly (expo-doctor flags the latter); the generated metro.config.js extends expo/metro-config with mergeConfig from @expo/metro/metro-config. - metro-config/metro-resolver are marked optional peer dependencies since they are only needed for SDK 53/54.
|
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
👷 Deploy request for nx-docs pending review.Visit the deploys page to approve it
|
Expo SDK 55+ publishes @expo/cli with an exports map ("./*": "./*.js"), so
require.resolve('@expo/cli/build/bin/cli') now fails with MODULE_NOT_FOUND
because the bin file 'build/bin/cli' has no .js extension. This broke the
start, run, export, serve and prebuild executors (e.g. 'nx prebuild' →
Cannot find module '.../@expo/cli/build/bin/cli.js').
Resolve the CLI via the stable 'expo/bin/cli' entry point (the same one
'npx expo' uses), falling back to the legacy path for older SDKs.
itsjithinv
force-pushed
the
feat/expo-sdk-56-support
branch
from
490bfd6 to
56349b2
Compare
👷 Deploy request for nx-dev pending review.Visit the deploys page to approve it
|
👷 Deploy request for nx-dev pending review.Visit the deploys page to approve it
|
👷 Deploy request for nx-dev pending review.Visit the deploys page to approve it
|
👷 Deploy request for nx-dev pending review.Visit the deploys page to approve it
|
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Current Behavior
@nx/expocurrently supports only Expo SDK 53 and 54, and new projects default to SDK 54.There is no way to scaffold or migrate to SDK 55 or 56. Any newer SDK version falls back to the SDK 54 version set.
Separately, the plugin’s Metro integration assumes the standalone
metro,metro-config, andmetro-resolverpackages. It also forces Metro’sprojectRootto the workspace root. Both behaviors are incompatible with the@expo/metropackage family introduced in SDK 55.As a result, generated SDK 55 and 56 apps crash during bundling with:
Expected Behavior
@nx/exposupports Expo SDK 55 and 56, with SDK 56 used as the default for new apps.This includes:
Full, npm-verified version matrices for:
SDK 55:
0.83.6@expo/cli~55.0.32jest-expo~55.0.18SDK 56:
0.85.3@expo/cli~56.1.14jest-expo~56.0.419.2SDK detection recognizes Expo majors 53 through 56.
Existing SDK 53 and 54 workspaces keep their exact version sets.
Metro integration is now SDK-aware:
withNxMetroand the Nx resolver use:@expo/metro/metro-config@expo/metro/metro-resolverSDK 53 and 54 continue to fall back to the standalone Metro packages.
On SDK 55 and newer,
withNxMetrono longer overrides Metro’sprojectRootto the workspace root.Expo’s Babel transformer now resolves the app’s
.babelrc.jscorrectly.Workspace libraries remain resolvable through:
watchFoldersnodeModulesPathsresolveRequestNew SDK 55 and newer apps no longer install standalone
metro-config,metro-resolver, or@expo/metro-configdirectly.Generated
metro.config.jsfiles now extendexpo/metro-config.metro-configandmetro-resolverare now optional peer dependencies.A new migration,
update-23-0-0-create-ai-instructions-for-expo-56, provides upgrade guidance for SDK 56.Verification
Verified with:
version-utilsunit tests, 30/30 passing, covering SDK 55 and 56 selection.--preset=expoworkspace generating a real SDK 56 app.expo start --weband no manual configuration.Related Issue(s)
Fixes #35714