File value ​​in sourcemap are inconsistent

[mo36924]

Describe the bug

Wrong value for file in source map.

When you run npm run build on stackblitz, dist/assets/a-BPnjg4Tj.js.map is created.
The file value of dist/assets/a-BPnjg4Tj.js.map is assets/a-BPnjg4Tj.js, but it is actually a-BPnjg4Tj.js.

In the process below of the vite:build-import-analysis plugin, the value of file is overwritten with the value of chunk's fileName.

vite/packages/vite/src/node/plugins/importAnalysisBuild.ts

Lines 714 to 721 in 302f809

	const map = combineSourcemaps(chunk.fileName, [
	nextMap as RawSourceMap,
	chunk.map as RawSourceMap,
	]) as SourceMap
	map.toUrl = () => genSourceMapUrl(map)
	const originalDebugId = chunk.map.debugId
	chunk.map = map

Reproduction

https://stackblitz.com/edit/vitejs-vite-e2fe1pxb

Steps to reproduce

Run npm install followed by npm run build

System Info

StackbBlitz
  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    vite: ^7.1.7 => 7.1.7

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.

[hi-ogawa]

I'm not sure if there's absolute correct or wrong in this file field. It seems like https://tc39.es/ecma426/#sec-source-map-format suggests to put anything "reasonable":

The file field is an optional name of the generated code that this source map is associated with. It's not specified if this can be an URL, relative path name, or just a base name. Source map generators may choose the appropriate interpretation for their contexts of use.

Could you explain why it's preferred to "file":"a-BPnjg4Tj.js" instead of "file":"assets/a-BPnjg4Tj.js"?

[mo36924]

Sorry. Wrong wasn't right. I will correct the title.

Currently the output file value is inconsistent.

Case where preload code is inserted in vite.
Run npm run build on the page below.
https://stackblitz.com/edit/vitejs-vite-e2fe1pxb
↓
dist/assets/a-BPnjg4Tj.js.map

{ ..., "file":"assets/a-BPnjg4Tj.js" }

dist/assets/b-BQUyiZa0.js.map

{ ..., "file":"b-BQUyiZa0.js" }

Case where preload code is not inserted in vite.
Run npm run build on the page below.
https://stackblitz.com/edit/vitejs-vite-ntvvfeha
↓
dist/assets/a-BMSuVuIA.js.map

{ ..., "file":"a-BMSuVuIA.js" }

dist/assets/b-BQUyiZa0.js.map

{ ..., "file":"b-BQUyiZa0.js" }

Could you explain why it's preferred to "file":"a-BPnjg4Tj.js" instead of "file":"assets/a-BPnjg4Tj.js"?

If no preload code is inserted in vite, or if rollup or rolldown is used alone, the file value of sourcemap is a relative path starting from sourcemap. Therefore, even when inserting preload code, it is better to use relative paths from the source map without asset prefixes.

[hi-ogawa]

Thanks for the explanation. I don't think this is something intended, so keeping file unmodified sounds good. Btw, do you happen to have any concrete issue because of this inconsistency maybe with other source map tooling?

[mo36924]

do you happen to have any concrete issue because of this inconsistency maybe with other source map tooling?

Nothing in particular.
As far as I know, I haven't had any problems with other source map tools.

I noticed this problem when I tried to use this file value to link a source map to source code in my own program.

[ivan-klass]

I'm exepriencing a similar issue related to source reference resolution.

I got a bunch of annoying "points to missing source files" errors, that really are false-positives (browser maps sources succesfuly).

Setup:

In my vite project I'm inluding a generated js file that is built from other sources. If simplified, my project looks like:

vite-project/
    generated/
        foo.js
        foo.js.map
        bar.js
        bar.js.map
        main.js
        main.js.map
    index.html
    src/
      app/
          foo.source
          bar.source
          main.source
      main.js
    vite.config.js

the src/main.js is as simple as

import '../generated/main.js'.

The ../generated/main.js itself has imports of

import * as foo from './foo.js'
import * as bar from './bar.js'

Note that every js file in generated/ file has a valid source map.
These source maps reference absolute URIs for both local source files and some open-source libraries, like:

"sources": [
    "file:///absolute/path/to/vite-project/src/app/Main.source",
    "https://raw.githubusercontent.com/org/repo/version/src/Lib.source"
]

The problem is that in vite I got a bunch of strange errors like below (added --debug sourcemap to vite):

  Sourcemap for "/absolute/path/to/vite-project/generated/foo.js" points to missing source files
    vite:sourcemap Missing sources:
    vite:sourcemap   /absolute/path/to/vite-project/generated/file:/absolute/path/to/vite-project/src/app/foo.source
    vite:sourcemap   /absolute/path/to/vite-project/generated/https:/raw.githubusercontent.com/org/repo/version/src/Lib.source

So it seems that vite forcefully adds an incorrect sourceRoot (base directory of the js file) to any source referenced in sourcemap even if URIs are already absolute.

I believe that patch should be applied somewhere here - if the source uri is already absolute, it should NOT resolve against sourceRoot.

Also note that double-slashes for uri scheme were replaced (file:/ and https:/).
Hope this helps.

[hi-ogawa]

@ivan-klass I haven't read through all but that's likely a different issue. This issue is specifically the edge case of file unexpectedly mutated for specific situation. I'd appreciate opening an issue with a reproduction to have a better look of your issue. (sources or sourceRoot fields are more crucial, so if there is a bug with that, the issue should be treated separately.)