Using sourceURL and sourceMappingURL with relative paths - google-chrome-devtools

Question

It appears that sourceURL is made relative differently in Firefox and Chrome - when some tooling generates //# sourceURL=... strings in JS files that are relative to the file they are placed in, Firefox treats the URL as relative to the JS file, while Chrome instead treats it as relative to the original HTML file. Which is correct, or is there a clearer way to state this?
In this sample application, I'm trying to use sourceURL to allow many, smaller files to be combined into a single large file but still allow the browser to know what the smaller file should be called, and sourceMappingURL to then specify the sourcemap file, relative to that original file.
Directory structure:
index.html
js/
all.js
uncompiled/
app.js
app.js.map
app.min.js
The index.html is a minimal page to load either js/all.js or js/uncompiled/app.min.js. There is no other JS being baked into js/all.js (as this is a minimal example), but in theory there could be many here. The purpose of this file is just to combined the various minified JS files into one larger file, yet still allow the developer to see the original code, and set breakpoints accordingly.
Contents of app.js:
class App {
constructor(name) {
this.name = name;
}
sayHi() {
window.alert("Hello " + this.name);
}
}
new App("Colin").sayHi();
Then, running a simple minifier rebuilds that into app.min.js with a matching app.js.map file:
var App=function(a){this.name=a};App.prototype.sayHi=function(){window.alert("Hello "+this.name)};(new App("Colin")).sayHi();
//# sourceMappingURL=app.js.map
{
"version":3,
"file":"./app.min.js",
"lineCount":1,
"mappings":"AAAA,IAAMA,IAELC,QAAW,CAACC,CAAD,CAAO,CACjB,IAAAA,KAAA,CAAYA,CADK,CAIlB,IAAA,UAAA,MAAAC,CAAAA,QAAK,EAAG,CACPC,MAAAC,MAAA,CAAa,QAAb,CAAwB,IAAAH,KAAxB,CADO,CAKTC,EAAA,IAAIH,GAAJ,CAAQ,OAAR,CAAAG,OAAA;",
"sources":["app.js"],
"names":["App","constructor","name","sayHi","window","alert"]
}
And finally, that minified output is wrapped in eval, and the sourceURL param is added to the end (line breaks added for readability):
eval('var App=function(a){this.name=a};App.prototype.sayHi=function
(){window.alert("Hello "+this.name)};(new App("Colin")).sayHi();\n
//# sourceMappingURL=app.js.map\n//# sourceURL=uncompiled/app.min.js');
If the index.html directly points to js/uncompiled/app.min.js, then both Firefox and Chrome correctly understand that app.js.map is in the same directory, and should be used when debugging. However, if index.html points instead to js/all.js, then while both browsers correctly show the eval'd contents in an individual file, only Firefox makes the path relative to all.js.
Using python -m http.server on this structure shows these results in firefox:
127.0.0.1 - - [14/Jun/2019 08:33:37] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:37] "GET /js/all.js HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:38] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:33:38] "GET /favicon.ico HTTP/1.1" 404 -
127.0.0.1 - - [14/Jun/2019 08:33:41] "GET /js/uncompiled/app.js.map HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:41] "GET /js/uncompiled/app.js HTTP/1.1" 200 -
On the other hand, here is what Chrome attempts:
127.0.0.1 - - [14/Jun/2019 08:34:22] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:34:22] "GET /js/all.js HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:34:22] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:34:22] "GET /uncompiled/app.js.map HTTP/1.1" 404 -
127.0.0.1 - - [14/Jun/2019 08:34:23] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:34:23] "GET /favicon.ico HTTP/1.1" 404 -
Chrome appears to be assuming that the sourceURL within js/app.js is relative to index.html, while Firefox instead (correctly, from my perspective) interprets it as being relative to app.js. I suggest that Firefox is correct since this permits any HTML file to include that JS, at any path, and still have the sourcemaps loaded correctly.
Example sources, including two html files at different relative paths: https://github.com/niloc132/sourceurl-and-sourcemapping-url-relative-paths

Answer 1

From the spec (or the copy at https://sourcemaps.info/spec.html):
When the source mapping URL is not absolute, then it is relative to the generated code’s “source origin”. The source origin is determined by one of the following cases:
If the generated source is not associated with a script element that has a “src” attribute and there exists a //# sourceURL comment in the generated code, that comment should be used to determine the source origin. Note: Previously, this was “//# sourceURL”, as with “//# sourceMappingURL”, it is reasonable to accept both but //# is preferred.
If the generated code is associated with a script element and the script element has a “src” attribute, the “src” attribute of the script element will be the source origin.
If the generated code is associated with a script element and the script element does not have a “src” attribute, then the source origin will be the page’s origin.
If the generated code is being evaluated as a string with the eval() function or via new Function(), then the source origin will be the page’s origin.
In the case of js/all.js, it falls in the last case: the source origin will be the page's origin. So it would appears that Chrome is following the spec, even though that might seem counter-intuitive.