fix: only copy in-project symlinks

[jun-sheaf]

What?

Instead of copying symlinks in standalone builds, we resolve them to their realpath and copy the actual file.

Why?

By their nature, symlinks are not meant for standalone builds. If they resolve to a path somewhere else, that path needs to exist at runtime which may not be the case. E.g. we use Bazel where node_module dependencies are sandboxed and symlinked during build. This implies Next.js will copy over these symlinks built for the sandbox which will break once the sandbox is destroyed.

How?

Instead of using reallink, we use realpath.

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: cc21d5e

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[jun-sheaf]

@ijjk Gentle ping. Could you please take a look?

[ijjk]

Hi, this doesn't seem correct as it is valid to have a relative symlink like with pnpm's node_module's handling which we want to handle. Instead we should be only copying the file if it is outside of the detected project root.

If we aren't copying when we detect outside of the project root could we add a test case and ensure the above described behavior is occurring?

[jun-sheaf]

If we aren't copying when we detect outside of the project root could we add a test case and ensure the above described behavior is occurring?

Could you point to where I should add the test?

this doesn't seem correct as it is valid to have a relative symlink like with pnpm's node_module's handling which we want to handle.

In a mono-repo, this will fail because pnpm will link outside the package root.

[vercel]

@jun-sheaf is attempting to deploy a commit to the Vercel Partnerships Team on Vercel.

A member of the Team first needs to authorize it.

[jun-sheaf]

It looks like there are bigger problems than just the symlinks when trying to build this through Bazel. More specifically, because the .pnpm folder is outside the project root, even if you copy the direct dependencies, the indirect dependencies won't exist. I don't expect next.js to reconstruct the folder so I'll close this as out of scope.

For Bazel users, the solution we used was to wrap the CLI and run pnpm install in the standalone directory after it's constructed.