Source Map support in Firefox?

[MicahZoltu]

I have a module that lives at <root>/apple.js. In it there is a //# sourceMappingURL=apple.js.map. However, when the browser tries to load that sourcemap it can't find it. I suspect it has to do with the whole blob:... stuff, but I don't understand it well enough to speculate beyond that.

Source map error: TypeError: apple.js.map is not a valid URL.
Resource URL: blob:http://localhost:8081/033273b5-1e9d-4506-8bb5-cd301e633116
Source Map URL: apple.js.map

note: Source maps appear to work in Chrome.

[guybedford]

What we could do here is automatically rewrite the sourceMappingURL when doing the transformation. This should be straightforward I think.

[coreyoconnor]

I think that makes sense. Rewrite to have the absolute path from the URL?

[guybedford]

@coreyoconnor if you're interested in testing this out, it should work by adding the following line just before https://github.com/guybedford/es-module-shims/blob/master/src/es-module-shims.js#L139:

resolvedSource = resolvedSource.replace(/\/\/# sourceMappingURL=(.*)\s*$/, (match, url) => match.replace(url, new URL(url, load.r)));

[just-dont]

Unfortunately, I have exactly the same issue with 0.4.5 as original author:

Source map error: TypeError: Invalid URL: index.js.map
Resource URL: blob:https://localhost/81c3bed4-7cd1-4cba-be42-0e4854973f16
Source Map URL: index.js.map

It doesn't seem like this one was fixed properly.

[coreyoconnor]

For the record: I have not tested the new release.

…

On Mon, Sep 30, 2019 at 4:58 AM just-dont ***@***.***> wrote: Unfortunately, I have exactly the same issue with 0.4.5 as original author: Source map error: TypeError: Invalid URL: index.js.map Resource URL: blob: https://localhost/81c3bed4-7cd1-4cba-be42-0e4854973f16 Source Map URL: index.js.map It doesn't seem like this one was fixed properly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAAIMDKLFIM6FKE54QX6HTDQMHSXNA5CNFSM4GSCSXN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75MSJY#issuecomment-536529191>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAIMDOKSI6D76QTJXOD2L3QMHSXNANCNFSM4GSCSXNQ> .

[MicahZoltu]

FWIW, 0.4.5 source maps are working for me in general in Firefox. However, stack trace links are not working. If I throw an error from inside a module that was loaded with es-module-shims, the links in the stack trace open up a new browser window with the source code (they are basically just links to source code files, not normal stack trace lines).

Also, in one of my projects using 0.4.5 the links don't open at all because they are missing the protocol/domain name and so the link tries to open view-source:http://package-name/path/to/file.js, which of course doesn't exist.

What does work is that source maps are fetched in the browser debugger and I can put breakpoints in those source files. It is just stack traces that aren't functioning correctly.

[just-dont]

Well, source maps in FF were always much more flaky than in Chrome. I've run additional tests, and it still seems exactly as the original reported issue: my source maps are working absolutely fine in Chrome, but they aren't working at all in FF. It's probably an issue with Firefox itself, but I'm not even sure how to report it to Mozilla - I don't understand what exactly is going wrong in the first place.

[MicahZoltu]

@just-dont Are you able to create a small repository that reproduces the issue? None of my projects have that problem since this issue was fixed/closed.

[just-dont]

@MicahZoltu I made a repo that basically has nothing except the basic outline of a build process that I use. You can look at it here - https://github.com/just-dont/sourcemaps-with-shims

[MicahZoltu]

I suspect your problem is related to rollup. Are you able to reproduce the problem without rollup in the mix?

[just-dont]

No it's not. The problem appears after all build steps are done and only in one browser. I can't imagine any possible way the bundler might affect this. You can argue that bundler and its plugins definitely affect the content of the sourcemap, but you have to realize that sourcemap content doesn't even come into play here. The map itself does not load at all - the only thing that matters at this step is sourceMappingURL.

But also we have different libraries built in pretty much the same way using webpack and demo'ed using webpack dev server. And guess what - it doesn't matter.

[MicahZoltu]

I'm not suspicious of the bundling process, I'm suspicious of the rollup file server. After doing an npm run build, I am unable to host the site with a static file server and have it function out of the box. This shows that rollup file server is doing some magic. For example, it is making node modules available at the root of the web server, even though they don't exist at the root of the web server. So Rollup is doing some magic, and the question is whether that magic is the source of the poor interaction with es-module-shims.

This isn't to say that there isn't a bug in es-module-shims, just that I suspect the whatever the bug is is related to the rollup file server. I have many projects that do not have any special file server like rollup/webpack (just generic static file server that knows nothing about my project) that all work with es-module-shims. The immediate difference I see between those projects and yours is the rollup file server that is doing magic path transformations behind the scenes.

[just-dont]

I'm not suspicious of the bundling process, I'm suspicious of the rollup file server. After doing an npm run build, I am unable to host the site with a static file server and have it function out of the box. This shows that rollup file server is doing some magic.

Yeah. It bundles the demo, which, given the empty example, pretty much equals to renaming demo.js to index.js, and assembling sourcemap for it. You can host the site just fine (without sourcemap ofc) if you do the renaming yourself. Well, and you also have to explain the browser how to resolve '../dist/lib' import.
Or you can just look at index.js file rollup had created - there's no magic in it.

[MicahZoltu]

To help you isolate the problem, see the project here: https://github.com/MicahZoltu/browser-es-modules-template (instructions in readme). That is served with a static file server that does no server-side magic.

[just-dont]

Your sources from blob:

//# sourceMappingURL=index.js.map
//# sourceMappingURL=http://127.0.0.1:8080/output/index.js.map
//# sourceURL=http://127.0.0.1:8080/output/index.js

My sources from blob:

//# sourceMappingURL=index.js.map

//# sourceURL=http://localhost:8888/index.js

My guess is that this pretty much means that solution outlined in this issue doesn't get applied in my case.

[MicahZoltu]

After much troubleshooting I figured out the problem. If there is a newline at the end of the file (which means at the end of the sourceURL line) then Firefox won't even try to fetch the file.

I'm not sure if this is a bug in Firefox, or a bug in es-module-shims. @guybedford may have a better idea of what the source of such an error could be.

[just-dont]

Yeah, I looked at the code and realized that the only problem that I can see at all might be with determining lastNonEmptyLine variable in es-module-shims. I'll debug this in a bit.

PS: By the way, @MicahZoltu many thanks for poking at this issue and giving me nice food for thought. We'll probably figure it out now :)

[just-dont]

Okay, so the gist of the situation is that trying to determine some content at the end of file based on location of the last '\n' is not very effective: there might be some extra line breaks, whitespace, whatever. The standard states that //# sourceMappingURL must be placed at the end of file, however, that statement is not explicitly strict about possible whitespace and/or line breaks.

I replaced operations based on lastNonEmptyLine with explicit search for source mapping via .lastIndexOf(`//# sourceMappingURL=') and it started to work.

[MicahZoltu]

A file could have //# sourceMappingURL= in it somewhere else, but not be using source maps. For example, a page that talks about source maps or describes how to use them may include that line.

If the spec says that it must be at the end of the file then I think the bug here is actually in rollup.

[just-dont]

If the spec says that it must be at the end of the file then I think the bug here is actually in rollup.

If we treat that very literally - then es-module-shims breaks all source maps by adding content after //# sourceMappingURL.

As I said, the 'end of file' statement is not terribly strict and trying to apply some additional limitations to it is very much thin ice.

I guess I'll change detection to be \n//# sourceMappingURL=<symbols except \n><optional \n>

[MicahZoltu]

If I were you, I would submit a GitHub issue to rollup to fix their problem, and submit a patch to es-module-shims that makes the matcher ignore trailing CR, LF, TAB, and SPACE (the most likely accidental trailing whitespace characters).

[just-dont]

I can't really complain to rollup devs (and webpack devs too, by the way) that some other code that blindly cuts sources by '\n' might break because there's a CR+LF slipped after sourceMappingURL.

Especially given that the same other code then pastes its own text after sourceMappingURL line.
As for the PR to es-module-shims -- that's the general idea. Although I don't like the idea of being needlessly precise here.

PS: By "needlessly precise" I mean that browsers don't mind at all if //# sourceMappingURL will happen in the middle of a file. They WILL try to load it. The "end of the file" statement from standard seems to apply only in a sense that the last sourceMappingURL wins if there are more than one.

[MicahZoltu]

I filed an issue with rollup to see if they can fix it on their end as well. When the specification is vague as this one is, I think it is best for tools like Rollup to be as compatible as possible, which means not including the extra newline in their generated file.

rollup/rollup#3148