Bug report

What is the current behavior? When a build includes context modules where the regular expression contains something which looks like a relative path, Webpack generates a source map with an incorrect source name that turns the regular expression into an absolute path.

This causes a mismatch in the getTaskForFile method of the SourceMapDevToolPlugin because the actual module id in the compilation, only has the leading path of the context module as absolute:

The consequence of which, is that rather than passing the module instance, it passes the (malformed) string module ID to ModuleFilenameHelpers.createFilename to generate the source map source name. This in turn causes the logic in createFileName to not be able to use ContextModule.readableIdentifier to create the friendly identifier that it should for context modules. Instead it will just use the mangled identifier as-is and push that into the source map.

The root of the path will be turned relative to the compiler context again; but the absolute path portion wrongly appended to the regex inside the identifier will remain and will leak into the source maps. This has the potential of changing content based on what machine actually ran the build from what directory structure, meaning caches being busted if content-hashes are added. Moreover; the fact that it leaks the directory structure of the build machine, means it also leaks the type of build agent and environment that was used - which might be information you don't want to slip to the public.

If the current behavior is a bug, please provide the steps to reproduce. (note: still working on extracting a minimal reproducing case)

What is the expected behavior? Webpack should not exhaustively attempt to make absolute paths from all pipe (|) separated components. It should only do so for the first component of a pipe-separated sequence.

Other relevant information: webpack version: 5.74 Node.js version: Operating System: Windows 10 Additional tools: