fix: ignore ENOENT in injectSourcesContent

[aleclarson]

Description

This is important for virtual modules and malformed source maps, both of which can throw ENOENT errors when injecting sourcesContent into source maps.

Solution

Expect sourcemaps for virtual modules to either contain a pre-populated sourcesContent array or have a sources array of absolute paths only. Otherwise, a warning will be printed (at most one time).

Expect sourcemaps for normal modules to either contain a pre-populated sourcesContent array or have a sources array that never points to non-existent files. Relative source paths are allowed, and they're resolved with sourceRoot (if defined) or the parent directory of the module. When a non-existent source is found, a warning will printed (at most once per sourcemap for the lifetime of the Vite server).

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

Would it be possible to differentiate between malformed source maps and virtual modules so we can emit a warning when the maps are malformed instead of a silent ignore? Also, do you think it is possible to add a test case?

[Shinigami92]

Is this p2-nice-to-have or p3-minor-bug?

[aleclarson]

Would it be possible to differentiate between malformed source maps and virtual modules so we can emit a warning when the maps are malformed instead of a silent ignore?

Maybe, should we bring this up with Evan?

[dimfeld]

Am I correct that with the changes to this PR it now throws errors once again in the "malformed sourcemap" case, as it currently does? I think it would be very helpful if malformed source maps in dependencies, whether from bad paths or just failure to package the source with the NPM package, didn't completely kill the build.

This is an especially sensitive case IMO because it mostly comes up with dependencies where there's a much longer turnaround to get the source maps fixed.

[aleclarson]

@dimfeld That's a good point. It's not a fatal error, so we shouldn't kill the build. 👍

[aleclarson]

@patak-js @antfu This PR has been reworked and rebased.
Please read the "Solution" section in the OP, and review the code. Thx

[HerringtonDarkholme]

Hi @patak-js, I wonder if this PR could be released to a new version of Vite soon? Thanks!

[patak-dev]

We are doing one release per week, it will be out next tuesday

[wmzy]

Hi @aleclarson and @patak-js ,
I also encountered this bug.
I debug and found the transformResult.map.sourcesContent will be excluded always:

vite/packages/vite/src/node/server/transformRequest.ts

Lines 131 to 152 in 828a8e5

	const transformResult = await pluginContainer.transform(code, id, map, ssr)
	if (
	transformResult == null ||
	(isObject(transformResult) && transformResult.code == null)
	) {
	// no transform applied, keep code as-is
	isDebug &&
	debugTransform(
	timeFrom(transformStart) + chalk.dim(` [skipped] ${prettyUrl}`)
	)
	} else {
	isDebug && debugTransform(`${timeFrom(transformStart)} ${prettyUrl}`)
	code = transformResult.code!
	map = transformResult.map
	}
	if (map && mod.file) {
	map = (typeof map === 'string' ? JSON.parse(map) : map) as SourceMap
	if (map.mappings && !map.sourcesContent) {
	await injectSourcesContent(map, mod.file, logger)
	}
	}

The transform will call

vite/packages/vite/src/node/utils.ts

Line 434 in 828a8e5

export function combineSourcemaps(

to combine sourcemap which will call remapping with excludeContent option as true.

[patak-dev]

@wmzy do you see an issue then with the way this PR is implemented? Could you create a bug report if that is the case?

[wmzy]

@patak-js this PR fixed the bug in injectSourcesContent .
But in my case, the injectSourcesContent shoud not been call if the pluginContainer.transform has not lost the sourcesContent.

I will try a PR to optimize this. It's hard to explain with my poor English.

[wmzy]

@patak-js The PR has been created, could you review it?