Pruning of sourcemap comments is too agressive

[IvanSanchez]

Be advised this is an edge case.

I discovered this while working with my rollup-plugin-file-as-blob workflows. In order to reproduce the bug:

• Have a *.js file with a //# sourceMappingURL= comment at the end
• Include that file as a blob:// URL via rollup-plugin-file-as-blob
• Try to parse the resulting code

My plugin returns module code as follows:

export default __$strToBlobUri("Contents of a plain-text file goes here", "text/plain; charset=us-ascii", false);

Which, for a javascript file, might look like:

export default __$strToBlobUri("\"use strict\";foobar();\n//# sourceMappingURL=something.js.map\n", "text/plain; charset=us-ascii", false);

The code from 9164f80 will take that module code, run the regexp, not notice that the sourcemap comment is inside a string literal, then strip the closing " and the rest of the line, i.e.:

export default __$strToBlobUri("\"use strict\";foobar();\n

That will obviously break all kinds of havoc in the parsers.

I think I can work around the bug in my plugin code, given that this is an edge case involving custom rollup plugins. Nonetheless I'd appreciate if rollup handling of sourcemap comments (9164f80) could be a bit less naïve.

[IvanSanchez]

I worked around this in https://gitlab.com/IvanSanchez/rollup-plugin-file-as-blob/commit/24d64f5e3e40c3d73e8c6e72100f1c85da5356f5?view=inline. Unless somebody else hits the problem, I guess this can be considered ultra-low priority.

[btd]

It looks like #1056. I got the same problem when worked on css modules

[Rich-Harris]

This is fixed now – the regex for matching sourceMappingURL comments has a ^ at the start

[btd]

just for reference, fix proposed does not work for such case:

var str = `
//# sourceMappingURL=...
`
console.log(str);

I still get failled test in my plugin.