[robhogan]

This enables resolver.unstable_applyBrowserSpecAfterExports (#2134) and resolver.unstable_resolveExportsFromPackageRoot (#2160) by default for 0.88.

Both were introduced as opt-in in 0.87.3. They are strictly more correct (or more ecosystem aligned, where there's no authoritative spec), but it is possible this will break edge cases that rely on Metro's previous behaviour, intentionally or not.

For a bare specifier, "exports" now comes from the package.json at the root of the named package, as in Node, webpack 5 and Vite 8, so a nested package.json no longer hides it.

An object-valued "browser" (or "react-native") field now redirects the file that "exports" resolves to, rather than the requested subpath.

Some packages that rely on the old behaviour to reach a build that works on native:

• msw/native (msw 2.15) moves to the Node build of @mswjs/interceptors, which requires node:zlib.
• react-dom/server and react-dom/static move to their Node builds. react-dom/server.browser and react-dom/static.browser are still exported.
• import 'nanoid/async' (nanoid 3) moves to index.native.js, which requires expo-random. require('nanoid/async') still works.

Setting unstable_applyBrowserSpecAfterExports to false restores react-dom, and setting unstable_resolveExportsFromPackageRoot to false restores msw/native and nanoid/async. Setting the first alone sends nanoid/async to a Node build, so set both to get the previous behaviour back. We'll keep the options around for now to offer a fallback for users reliant on the previous behaviour, but they'll be removed in a major in the near future.

Fixes: #1135
Fixes: #1517
Fixes: #1582
Fixes: #2153

Changelog

 - **[Breaking]**: Resolver: Read `"exports"` from the package root, and apply `"browser"` redirections to the resolved file, by default (`resolver.unstable_resolveExportsFromPackageRoot`, `resolver.unstable_applyBrowserSpecAfterExports`)

Test plan

Existing tests pass unchanged.

AI-driven import graph walks through DependencyGraph, with both options off (as main) and on, using this branch and RN/Expo mainFields and conditions:

App, platform	Edges off -> on	Changed edges	New failures	Warnings off -> on
Bluesky iOS	25,081 -> 25,081	0	0	1 -> 0
Bluesky Android	24,981 -> 24,981	0	0	1 -> 0
Bluesky web	25,343 -> 25,343	2	0	2 -> 1
Mattermost iOS	13,843 -> 13,961	29	0	120 -> 120
Mattermost Android	13,816 -> 13,934	29	0	120 -> 120
pnpm fixture iOS	5,977 -> 5,977	0	0	1 -> 1

The changed edges are @floating-ui/utils/dom to its "exports" target on Bluesky web, and on Mattermost rxjs/operators from dist/cjs to dist/esm5 (matching rxjs) and nanoid/non-secure from index.js to index.cjs. The walks parse imports with Babel, so they miss transform-injected dependencies, and nothing has run on a device.

[github-actions]

Metro review: Looks good

Risk: medium · Commit: 8c3648c · 2 commands run

This turns on unstable_applyBrowserSpecAfterExports and unstable_resolveExportsFromPackageRoot by default. Both options shipped in #2134 and #2160, so this PR is the planned follow-up that changes their defaults, not a duplicate. The head is the same as in my previous review, and nothing I found blocks it. The defaults, the test context and the docs are consistent, and the new Troubleshooting section names the packages known to break and, for each one, which option restores it.

No findings.

Verified

• ✅ yarn jest --no-watchman packages/metro-resolver packages/metro-config packages/metro/src/DeltaBundler/__tests__/resolver-test.js — 15 suites, 629 tests
• ✅ yarn jest --no-watchman packages/metro/src packages/metro-config — 77 suites, 1109 passed, 1 skipped

Not run: I didn't re-run the author's app import-graph walks or the msw, nanoid and react-dom fixtures. They were checked against the earlier findings, and this head hasn't changed since my previous review. I didn't benchmark because the PR only changes two default config values, using code paths that already shipped as opt-in. I didn't check Windows: no machine was available, and the change doesn't involve paths.

_{Automated review by Claude. Advisory only: it never approves or blocks, and a maintainer makes the call.}

[github-actions]

nit · The react-dom escape hatch breaks nanoid/async, and the docs no longer warn about it

This bullet offers unstable_applyBrowserSpecAfterExports: false as a fix for react-dom/server, but that option alone doesn't restore 0.87 behavior. With it set to false and the root option left on, nanoid/async on iOS resolves to its Node build, for both import and require, and the bundle fails on crypto. Base resolves both forms to index.browser.cjs.

That also contradicts the nanoid/async bullet two lines down, which recommends require('nanoid/async'). The previous text in Configuration.md warned about this crypto failure, but this PR removed that warning.

Suggested fix: Prefer react-dom/server.browser in this bullet, and add one sentence to the section: unstable_applyBrowserSpecAfterExports: false alone can send packages with a nested "browser" map to a Node build, so set both options to false to get the previous behavior back.

_{Reproduced: bench/walk.js on a fixture with nanoid 3, comparing base defaults with head plus unstable_applyBrowserSpecAfterExports: false, iOS with RN main fields and conditions. nanoid/async went from index.browser.cjs to async/index.js (ESM) and async/index.cjs (CJS), with new failures nanoid/async/index.js -> crypto and nanoid/async/index.cjs -> crypto. Output is in bench/out/head-ios-nobrowser.json, summarized by bench/hatches.js. · id 7a1cccee}

[robhogan]

Reproduced with nanoid 3.3.20 and fixed in 8c3648c - the react-dom bullet now only suggests the .browser imports, and the section says to set both options to false to get the previous behaviour back.