Loading workspace insights... Statistics interval
7 days30 daysLatest CI Pipeline Executions
fca9059c feat(expo): support Expo SDK 56 (#35904)
## Current Behavior
`@nx/expo` supports Expo SDK 53–55 (latest/default 55) after the recent
version-lane refactor. It does not yet support **SDK 56**.
Separately, the plugin's Metro and executor wiring predates Expo's SDK
55
`@expo/metro` repackaging, so generated **SDK 55+** apps fail at runtime
even
on the existing lanes:
- `expo start` / web bundling crashes with
`TypeError: Cannot read properties of undefined (reading
'transformFile')` -
`withNxMetro` merges via the standalone `metro-config` and forces
`projectRoot` to the workspace root, which collides with Expo's bundled
`@expo/metro` and breaks the babel transformer's `.babelrc.js`
resolution.
- `nx prebuild` / `start` executors throw `Cannot find module
'@expo/cli/build/bin/cli.js'` because SDK 55+ ships `@expo/cli` with an
`exports` map (`"./*": "./*.js"`), so the hardcoded bin subpath no
longer
resolves.
## Expected Behavior
Adds an Expo **SDK 56** install lane (RN 0.85.3, React 19.2, `@expo/cli`
~56.1.14, `@expo/metro-config` ~56.0.13, `jest-expo` ~56.0.4) as the
default
for new projects, on top of the existing 53–55 lanes, and fixes the SDK
55+
runtime wiring (benefits 55 and 56):
- `withNxMetro` and the Nx resolver prefer `@expo/metro/metro-config` /
`@expo/metro/metro-resolver` (fallback to the standalone packages for
53/54),
and no longer override `projectRoot` to the workspace root on SDK 55+.
- Executors resolve the Expo CLI via the stable `expo/bin/cli` entry
instead of
`@expo/cli/build/bin/cli`.
- New SDK 55+ apps no longer install standalone
`metro-config`/`metro-resolver`
or `@expo/metro-config` directly (the generated `metro.config.js`
extends
`expo/metro-config`); those packages are now optional peer dependencies.
- Adds an AI upgrade-instructions migration for moving workspaces to SDK
56.
Verified by generating a workspace from a locally-published build:
`expo start --web` bundles successfully and `expo-doctor`'s
"`@expo/metro-config` installed directly" check passes.
## Related Issue(s)
Fixes #35714
---------
Co-authored-by: jithin_vijayan <jithinvijayan@vyaparapp.in>
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com> 5fbdca96 fix(core): prefer module.registerHooks to avoid DEP0205 deprecation warning (#36081)
## Current Behavior
To support TypeScript NodeNext-style relative imports under Node's
native type
stripping, Nx registers a small ESM resolution hook that rewrites
`.js`/`.mjs`/`.cjs` specifiers to their `.ts`/`.mts`/`.cts` sources. It
did this
with `module.register()`.
`module.register()` is runtime-deprecated on Node 25.9+ / 26+ (DEP0205),
so
loading a `.ts` config emitted a warning. For example, building a
project with a
TypeScript webpack config:
```
> webpack-cli build
(node:839660) [DEP0205] DeprecationWarning: `module.register()` is deprecated. Use `module.registerHooks()` instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
```
The build still succeeded; the warning was just noise.
## Expected Behavior
Nx now prefers `module.registerHooks()` (added in Node 22.15.0 /
23.5.0), which
runs the resolve hook synchronously in-thread and is not deprecated. No
more
`DEP0205` warning on Node 22.15+ / 24 / 26.
It falls back to `module.register()` only on older supported runtimes
that lack
`registerHooks` — Node `22.12.0`–`22.14.x` (within the current
`^22.12.0`
support floor, and CI-tested at `22.13.0`). On those versions
`module.register()`
is not yet deprecated, so the fallback stays silent.
Implementation notes:
- Added `nodeNextEsmResolveHook`, a synchronous in-thread twin of the
existing
inlined `data:`-module resolver (`NODENEXT_ESM_RESOLVER_SOURCE`). With
`registerHooks`, `nextResolve` throws synchronously rather than
rejecting a
promise, so the hook uses plain try/catch instead of `await`.
- The existing `isTsTranspilerPreloaded()` skip is kept for both paths
so
resolver coverage doesn't vary by Node version.
- The inlined `data:` source is retained for the fallback and marked as
such.
- Added unit tests mirroring all existing resolver cases against the new
synchronous hook.
The third-party ESM loader registration in `forceRegisterEsmLoader`
(`@swc-node/register/esm` / `ts-node/esm`) intentionally still uses
`module.register()`: those are asynchronous worker-thread loaders with
no
synchronous `registerHooks` equivalent, and that path only fires in a
niche
escalation (top-level await + TS syntax native strip can't handle).
## Related Issue(s)
N/A
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>