sources: clarify behavior on duplicate entries
#85
Labels
Comments
|
I'm in favor of adding to the spec they are invalid and then we can add a check on the validator (and generator tests) to check for them! |
|
For completeness sake, it turns out that for WebKit the behavior for duplicate sourcesContent is still set-like but it keeps the last entry that shows up instead. (see this code) |
|
The test that I used to check this was the following trivial set of files. I opened the debugger on the HTML file and looked at what original sources were shown in the buffer. <html>
<head>
<script src="duplicate.js"></script>
</head>
</html>// duplicate.js
let foo = 1;
//# sourceMappingURL=duplicate.js.map{
"version": 3,
"names": [],
"sources": ["foo.js", "bar.js", "foo.js", "foo.js"],
"sourcesContent": ["foo", "bar", "baz", "quux"],
"mappings":""
} |
|
VSCode behaves like Safari and keeps the last entry, so there is a 2-2 split. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the spec doesn't have much to say about duplicate entries in
sources:In practice, browsers can consume source maps with duplicates. For example, there's a PR for the Mozilla source-map library (mozilla/source-map#72) that makes sure it can consume maps with duplicates (but will not generate them).
In Chrome and Firefox at least, when there are duplicates the
sourcesentry is effectively used as a key into a set, so that the duplicate entries will refer to the same source file. If multiplesourcesContententries are specified, only the first one for the duplicated key is used. This is also true if the key isnull.Mappings will refer to whatever the source is in the set, regardless of the actual index, and whether it had a different
sourcesContentbased on index.IMO, it could make sense for the spec to say that duplicate entries in
sources(andnamespossibly) are invalid and that generators shouldn't produce them. Although there is a question of what equality you use for deciding if an entry is a duplicate (also brought up in #44 regarding source URL normalization), but at a minimum we could say they shouldn't be strictly equal as JS values.The text was updated successfully, but these errors were encountered: