next.js

904a4185 - Turbopack: retain conditions when replacing resolve request keys (#97372)

Turbopack: retain conditions when replacing resolve request keys (#97372) Closes https://github.com/vercel/next.js/issues/97358 `ResolveResult::with_replaced_request_key` overwrote the `conditions` of every result key with the conditions of the replacement key (empty at all call sites). Those conditions are what distinguishes the results one request resolved to under different export conditions, so both the `module-sync` and the `default`/`require` target of the same subpath ended up under the same `RequestKey`. That is lossy as soon as a request resolves in more than one `node_modules` directory: the results are merged through a `RequestKey`-keyed map, so one of the two targets is silently dropped. With a single candidate directory `ResolveResult::alternatives` short-circuits and never builds that map, which is why this only showed up in nested layouts. In practice this broke `output: 'standalone'` with the Turbopack production bundler for pnpm installs, whose virtual store hoists every package into `node_modules/.pnpm/node_modules` and thereby creates that second candidate directory: `next-server.js.nft.json` recorded only `@swc/helpers/cjs/_interop_require_default.cjs`, while Node >= 22.12 resolves `@swc/helpers/_/_interop_require_default` to the `module-sync` target `esm/_interop_require_default.js` (`@swc/helpers` 0.5.23 lists `module-sync` first). The copied `.next/standalone/server.js` then exited with MODULE_NOT_FOUND before listening. --------- Co-authored-by: vercel-fleet[bot] <308483924+vercel-fleet[bot]@users.noreply.github.com>