sourcemap is invalid when environment variables do not exist

[Beiluola]

Describe the bug

In the vitejs 5.0.12 documentation it was mentioned that environment variables would be replaced with undefined if they didn't exist, what I didn't expect was that this made sourcemap invalid. Maybe this is a feature rather than a bug. If that's the case, then I think it should be mentioned in the documentation, this saves developers time in locating problems.

Reproduction

https://stackblitz.com/edit/vitejs-vite-om3cbj?file=README.md&terminal=dev

Steps to reproduce

1. open the project using vscode
2. npm run build:env-sourcemap
3. add a breakpoint in the ./src/env-not-exist.ts file
4. open vscode javascript debugging terminal
5. node ./dist/env-not-exist.cjs
6. breakpoint not in effect
7. repeat the above steps in ./dist/ env-existence.cjs and./src/env-exist.ts, no problem

System Info

System:
    OS: macOS 13.0
    CPU: (8) arm64 Apple M1
    Memory: 63.05 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 8.19.4 - ~/.nvm/versions/node/v16.18.0/bin/npm
    pnpm: 8.10.2 - ~/.nvm/versions/node/v16.18.0/bin/pnpm
  Browsers:
    Safari: 16.1
  npmPackages:
    @vitejs/plugin-vue: ^4.5.2 => 4.6.2

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 vuejs/core 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.

[bolt-new-by-stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-om3cbj (Open reproduction)

[hi-ogawa]

Thanks for the reproduction. Indeed, source map seems broken when referencing non-existing import.meta.env keys in the code. I don't think this behavior is particularly intended (though it might be a technical limitation), so let me treat it as a bug.
(I also made a reproduction for non-lib build https://github.com/hi-ogawa/repro-vite-sourcemap-bad-meta-env and SSR dev hi-ogawa/repro-vite-ssr-error-stack#1)

From my investigation so far, I'm suspecting that this is caused by esbuild's source map including <define:import.meta.env> as an extra entry in sources (and main source being end up in 2nd entry):

• esbuild example 1

{
  "version": 3,
  "sources": ["<define:import.meta.env>", "<stdin>"],
  "sourcesContent": ["", "function main() {\n  console.log('hello', import.meta.env.VITE_NOT_EXIST);\n}\n\nmain()"],
  "mappings": "AAAA,uCAAE,KAAO,MAAM;ACAf,SAAS,OAAO;AACd,UAAQ,IAAI,SAAS,+BAAgB,cAAc;AACrD;AAEA,KAAK;",
  "names": []
}

This doesn't seem to happen when import.meta.env.XXX keys are properly replaced as a primitive, for example:

• esbuild example 2

I'm not familiar with how rollup combines multiple source maps from transform pipeline, but I think they don't expect there'll be multiple sources referenced from a single transform (as their doc mentions they only use mappings property https://rollupjs.org/plugin-development/#source-code-transformations).

To fix this, (assuming esbuild doesn't support controlling sources output) I think it's technically possible to manipulate esbuild's source map output and filter out all <define:...> related mapping segments and that'll probably save main source's mapping to be usable.

[Beiluola]

Thanks for the reproduction. Indeed, source map seems broken when referencing non-existing import.meta.env keys in the code. I don't think this behavior is particularly intended (though it might be a technical limitation), so let me treat it as a bug. (I also made a reproduction for non-lib build https://github.com/hi-ogawa/repro-vite-sourcemap-bad-meta-env)

From my investigation so far, I'm suspecting that this is caused by esbuild's source map including <define:import.meta.env> as an extra entry in sources (and main source being end up in 2nd entry):

• esbuild example 1

{
  "version": 3,
  "sources": ["<define:import.meta.env>", "<stdin>"],
  "sourcesContent": ["", "function main() {\n  console.log('hello', import.meta.env.VITE_NOT_EXIST);\n}\n\nmain()"],
  "mappings": "AAAA,uCAAE,KAAO,MAAM;ACAf,SAAS,OAAO;AACd,UAAQ,IAAI,SAAS,+BAAgB,cAAc;AACrD;AAEA,KAAK;",
  "names": []
}

This doesn't seem to happen when import.meta.env.XXX keys are properly replaced as a primitive, for example:

• esbuild example 2

I'm not familiar with how rollup combines multiple source maps from transform pipeline, but I think they don't expect there'll be multiple sources referenced from a single transform (as their doc mentions they only use mappings property https://rollupjs.org/plugin-development/#source-code-transformations).

To fix this, (assuming esbuild doesn't support controlling sources output) I think it's technically possible to manipulate esbuild's source map output and filter out all <define:...> related mapping segments and that'll probably save main source's mapping to be usable.

Thanks for your reply, it is a good idea, and I am happy to cooperate if needed.