Source maps broken due to injected __vite__mapDeps function after sourceMappingURL

[maximilianschmid]

Describe the bug

vite production build includes __vite__mapDeps function after //# sourceMappingURL=index-GR09PQxf.js.map

Reproduction

vite build with sourcemaps

Steps to reproduce

vite build with sourcemaps enabled in vite.config.mjs

build: { sourcemap: true },

System Info

Vite 5.0.8, NodeJS 20.10.0, MacOS 14.2

Used Package Manager

npm

Logs

Produced prodction JS file:

minified JS code…s,Te as t,At as u,Oc as v,$e as w,OE as x,Ta as y,Ste as z};
//# sourceMappingURL=index-GR09PQxf.js.map

function __vite__mapDeps(indexes) {
  if (!__vite__mapDeps.viteFileDeps) {
    __vite__mapDeps.viteFileDeps = ["assets/index-matuRVsK.js""]
  }
  return indexes.map((i) => __vite__mapDeps.viteFileDeps[i])
}

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] 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.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[DiFuks]

With this, there is another issue: I use the plugin @rollup/plugin-babel for transpiling to legacy browsers using the getBabelOutputPlugin mode. The code that Vite adds (__vite__mapDeps) is the only thing that doesn't get transpiled by this plugin because the addition occurs after the execution of the output plugins in Rollup.

[bluwy]

@DiFuks I think that's related to https://github.com/vitejs/vite/issues/15300. It's currently not possible to process the injected __vite__mapDeps as Vite only has the dependency information post-build.

[hi-ogawa]

Hi, I'm attempting to fix this issue in the PR https://github.com/vitejs/vite/pull/15483.

While trying to verify the fix, I noticed that the current behavior (i.e. //# sourceMappingURL comment appearing before __vite__mapDeps) seems to be actually fine for browsers (at least Chrome and Firefox I tested) and I'm a little worried that the issue you're experiencing might be different.

Could you elaborate how "Source maps broken" in what use case? Having a minimal repro would be also greatly appreciated as current test cases might be weak.

[maximilianschmid]

@hi-ogawa

Could you elaborate how "Source maps broken" in what use case? Having a minimal repro would be also greatly appreciated as current test cases might be weak.

-> Services like raygun.com can't handle source maps resolution if //# sourceMappingURL is not the last line