File System Paths in sources

[mitsuhiko]

This relates to the conversation about sources from #42. There is something curious going on with sources today in practice and it relates to how filenames and URLs are handled. An entry in sources is relative to the source map and the source map is relative to the transpiled javascript file. This makes sense, but in practice you will see that people stash actual file names into sources which are not on the same "namespace" or "origin" as the script.

Specifically in theory you can have https://foo.invalid/app/whatever.js as the minified file, then that refers to whatever.js.map which contains a sources entry called whatever.js which however is not the generated whatever.js but the original whatever.js (before minification). Strict reading of the specification says that this is illegal. In fact, quite a bit of tooling relies on the fact that source files are in fact placed somewhere on the same URL namespace so they can be fetched, but in practice it just happens that source refer to paths as they were on the file system originally. Some tools emit webpack://foo or similar to "move" files into a separate independent namespace, but I have also seen tools throw things like /path/to/builder into the structure. On Windows I have even see drive letters pop up which are definitely not valid URLs.

One effect can also be that the path moves past the URL root. I have seen a source map at /dist/foo.map which itself contains sources that are at ../../../node_modules/foo.js.

I'm not sure if this particularly actionable, but maybe there should be some guidances around what is acceptable and what is not.

[mitsuhiko]

Related issues:

• webpack sourcemap include absolute path webpack/webpack#15274
• Explore using urls instead of absolute paths in source-map 'sources' array webpack/webpack#8226
• Source map sources relative to temporary output path evanw/esbuild#2218
• Typescript sourcemaps resolve to absolute full path when running live vitejs/vite#4657
• mapRoot/sourceRoot write sourcemaps using absolute local paths, not URIs microsoft/TypeScript#25587

[jaro-sevcik]

In Chrome, we have struggled with several issues around source paths:

• Normalizing paths that contain . or .. segments. (crbug.com/1284737, crbug.com/1011729)
  • [Related] Duplicate filenames in 'sources' (after normalization). E.g., we see both webpack:///src/home/Home.vue and webpack:///./src/home/Home.vue in a source map. Is this the same file or not? (crbug.com/1304217)
• What if two different source maps contain the same 'sources' URL? Are those referring to the same file or two different ones? This typically happens with hot module replacement or with code splitting. (crbug.com/1404703, crbug.com/1409365, crbug.com/1111297, crbug.com/979000)
• Windows paths without file:. Is c:/a a URL with a c scheme or a windows path? (crbug.com/1323175)
• Resolving relative source paths in some of the corner cases (data URLs, redirection). (crbug.com/1383416, crbug.com/1403799, crbug.com/1277002)

[nicolo-ribaudo]

I have been exploring how Babel handles this, and it is... terrible. Apparently we just put the filename in sources, and not a path. babel/babel#15911 is partially changing it to use paths relative to the cwd when compiling (that usually matches with the project root), but I'm not really sure about what we should do.

[mitsuhiko]

I would be super curious if there is some sort of best practice at the moment.