Symlink resolved in entry module id regression

[khalwat]

Describe the bug

I have build setup that used to work in Vite pre 2.6, but now appears to be broken. In the Vite root dir, I have an symlink src/ that aliases to a directory outside of the Vite root. This is done for organizational purposes, when I build with manifest: true to output a manifest.json, the keys in the manifest used to look like this:

  "src/main.js": {

but now it resolves the symlink as part of the path:

  "../src/main.js": {

...which is not the desired result. Changing resolve.preserveSymlinks doesn't seem to have any effect.

It appears to resolve the symlink, and use that as the facadeModuleId , which appears to be a regression.

Reproduction

Steps to reproduce:

1. clone the repo: https://github.com/khalwat/vite-symlink-issue
2. cd buildchain then npm run build
3. Examine the output in buildchain/dist/manifest.json

Expected result:

• The manifest entry would match the import in index.html: "src/main.js"

Actual result:

• The manifest entry has the resolved symlink in the key: "../src/main.js"

System Info

n/a

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[michaelrog]

This broke my build as well.

Just to confirm I'm not misunderstanding... This is what resolve.preserveSymlinks is intended to address, right?

[khalwat]

Yeah I'm wondering if that preserveSymlinks PR could be the root cause #4708

[khalwat]

I can confirm that this is fixed in ^2.7.0-beta.10 -- I'm not sure which version of 2.7.0 specifically it was fixed, however.

[bluwy]

Thanks for the confirmation! Closing this as it's fixed in the beta version. 2.7.0 stable will be released soon.