Correlating original sources with sourcemapped scripts

[connor4312]

As discussed in the recent discussion (#22), a challenge and consistent point of difficult configuration for the VS/Code JS debugger is figuring out how compiled sources map to on-disk sources. It's easy when dealing with a simple sourcemaps containing absolute or relative filepaths on disk (i.e. in Node.js), but it can get increasingly complicated when introducing compilers, bundlers, and servers that might map a source to another arbitrary path.

Ideally such a mapping is independent of any source filesystems, such that two different users debugging the same code on a public webserver can have their sources map correctly; this rules out simply requiring absolute file URIs, not mentioning the leak of local filepaths that might happen.

The proposal for debug IDs maps transpiled code to their sourcemaps, but from my understanding does not go through to linking to the source code.

[connor4312]

A simple solution to the problem of mapping known local sources to unknown remote sources would be the addition of a sourcesHash: ["..."] property to sourcemaps, where the items of the array are hex-encoded SHA-256 hashes of the corresponding entry in the sources array.

Considerations:

• Any specific encoding used in creating the hash should be specified, namely because the similar hash used in V8's scriptParsed event is a hash of the source as UTF-8, which requires normalization if the source file is UTF-16 encoded or a BOM is included. I would suggest sourcemaps do the same thing that Chrome does here: tooling is likely to read the content into a string, which can be easily UTF-8 encoded (if not already), and having to re-read the file or restore a BOM is additional work.
• While the use of hex-encoded SHA-256 hashes may be verbose for bundles that include a large number of files, they should compress fairly close to their original 32 bytes.
• This would not readily solve mapping of known remote sources to unknown local sources, since doing so would require hashing all candidate files on the local disk. If there is desire for this, an alternative approach may be needed.

[mitsuhiko]

On the note of sourcesHash we have been generally been inlining sources into the source maps, even if that produces massive files. The reason is that this makes handling these files in practice much easier, sourcesHash is interesting, but not nearly as important as mapping between the minified artifact and the source map. As such the idea of using a SHA-256 hash to identify the minified file is useful, if that hash is also contained in the source map. One could imagine a fileHashSha256 key there.

That said I much prefer having explicit debug IDs as it can be supported without browser API support (an XHR request to the file to read the comment) and it addresses the issue of what happens if only one side changes.

[connor4312]

Yea, if sourcesContent is present, sourcesHash is not necessary. Inlinining them would be nice, but this is not the default for most tooling as far as I can recall. They're certainly not universal enough to depend on. For users who have sourcemaps on a remote server, having sourcesContent may not be desirable both for filesize and accessibility (if the sourcemap is publicly accessible.)

not nearly as important as mapping between the minified artifact and the source map

I think our use cases are different here. In js-debug, whose users are primarily iterating from a local or remote development server, mapping from artifact to sourcemap is never much of an issue. But I don't see debug IDs / sourcesHash as an "either/or" situation.

[mitsuhiko]

For what it's worth I definitely see a use for sourcesHash or what it's called to find the original sources. I would propose though when we discuss this we break up the mapping of minified artifact to source map from source map to original source mapping in the discussion, as those are I believe quite different problems that might warrant separate solutions.