Change sourcemap JSON order to match spec #2150
Conversation
From the spec https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6f AH0KY0k/edit?pli=1# the order should be: Line 1: The entire file is a single JSON object Line 2: File version (always the first entry in the object) and must be a positive integer. Line 3: An optional name of the generated code that this source map is associated with. Line 4: An optional source root, useful for relocating source files on a server or removing repeated values in the “sources” entry. This value is prepended to the individual entries in the “source” field. Line 5: A list of original sources used by the “mappings” entry. Line 6: An optional list of source content, useful when the “source” can’t be hosted. The contents are listed in the same order as the sources in line 5. “null” may be used if some original sources should be retrieved by name. Line 7: A list of symbol names used by the “mappings” entry. Line 8: A string with the encoded mapping data.
|
Cross-linking to fix on the libsass side sass/libsass#2193 |
|
The libsass version of this change has now landed |
|
I don't think the spec is intending to mandate this specific ordering—after all, JSON is inherently order-independent. I think it's just using those line numbers to point out where the sections it's referring to appear in the example source map. That's the a concrete benefit to having this ordering? |
nex3
added
needs info
|
Ensuring each one follows the spec will allow comparing of the sourcemaps at the file level in the spec side (although i don't think that is a goal currently). You're 💯 right that a JSON object doesn't really care about the order normally, and can just be parsed and compared by property. |
|
I'd rather have sass-spec compare the parsed maps than have to worry about textual identity of sourcemaps between implementations. |
From the spec the order should be: