next.js

afe476c6 - perf(build): use nft's cached readlink when collecting build traces (#99678)

perf(build): use nft's cached readlink when collecting build traces (#99678) ### What? Use nft's built-in cached `readlink` in `collect-build-traces.ts`. ### Why? - Since #56817, a custom `readlink` is passed to `nodeFileTrace`. Unlike nft's built-in one, it isn't cached, so every call goes to the filesystem. - nft's `realpath` walks up all parent directories again for every path it resolves, so with pnpm's deep `node_modules/.pnpm/...` layout these calls pile up. - In our app, `readlink` was called about 479k times for only about 9,100 distinct paths. - nft's built-in `readlink` also [returns `null` for the same error codes (`EINVAL` / `ENOENT` / `UNKNOWN`)](https://github.com/vercel/nft/blob/1.10.2/src/fs.ts#L72-L84), so removing it doesn't change behavior. `readFile` and `stat` are kept because they handle errors differently from the built-in ones. ### How? Removed the `readlink` option. Measured on our project (pnpm, Next 16.3, webpack build, `output: 'standalone'`): - Running only `nodeFileTrace` with the same inputs: 17.3–18.1s → 12.1–12.9s, with an identical list of traced files - "Collecting build traces" on CI (GitHub Actions, 2 vCPU): 42–57s → 26s - `.nft.json` files and the standalone output are identical before and after the change Fixes #100869 Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>