search

tc39 / source-map

Source map specification, RFCs and new proposals.
https://tc39.es/source-map/
Other
130 stars 17 forks source link

`sourceURL` in non-`eval` sources #125

Open nicolo-ribaudo opened 2 months ago

nicolo-ribaudo commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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

jridgewell commented 2 months ago

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:

jkup commented 2 months ago

@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 commented 1 month ago

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.