`sourceURL` in non-`eval` sources

[nicolo-ribaudo]

@legendecas can give more info, but it looks like Node.js is using //#sourceURL to map "virtual" files (created by transpiling TS on-the-fly) to their original filenames, without using a full source map. This is possible because in their implementation all the JS tokens are still in the original position, so mapping locations is not actually needed.

Does our spec support this use case, or does it only support the comment in eval()? In https://tc39.es/source-map/#linking-evald-code-to-named-generated-code says that it's for eval()'ed code, while in https://tc39.es/source-map/#linking-generated-code it also mentions it for "normal scripts".

[jkup]

It does look to conflict a bit. I think we can loosen or remove the first link and have it not mention eval. I think it should just say we allow sourceUrl and it takes priority over source maps.

[legendecas]

yeah, I think it is would be great to indicate that //#sourceURL can solely present in "normal scripts", without a //#sourceMappingURL.

[jridgewell]

I think it should just say we allow sourceUrl and it takes priority over source maps.

Turbopack uses both when eval()ing HMR'd updates:

• sourceUrl to provide a file name
• sourceMappingUrl to provide the updated source content of the file.

[jkup]

@legendecas @jridgewell thank you for the context! What is safe to say in the spec? I'd like to remove the with eval’d code and change evalSourceUrl to sourceUrl but maybe we don't say anything further for now? So we allow both browsers and bundlers to keep doing what they are currently doing?

[jridgewell]

Yah, removing references to "eval" seems good to me. See also https://bloomberg.github.io/ts-blank-space/ which is using sourceURL in a real (non-evaled) output file to correct the name of the file.