My dream spec text

[nicolo-ribaudo]

I have been thinking for a while about how I would like our spec to look like one day. The bar for publishing the spec is much lower than what I'd like the spec text to be, but it'd be great if one day we could reach this rigor and clarity.

• There should be some spec-level object/record, like ECMA-262 Records or WHATWG structs that represents a decoded source map
  • We should clearly define an algorithm to convert between JSON and this format. The algorithm doesn't need to be fast — it needs to be somewhat easy to understand and it's the source of truth for what the correct behavior is. Implementations can have their own faster algorithms, as long as they behave the same.
  • We should define the composition operation based on these records, i.e. compose(source map record, source map record) -> source map record
• There should be algorithms that take a source code string, a source map record, and return various info about it:
  • "what does the location X:Y in the original code correspond to in the running code?"
  • "what variables are visible from location X:Y in the original code?"
  • "what code do I need to run to get, from location X:Y, the value of the original variable foo"?
  • "what is the stack trace ... when remapped to the original code?"
• We should properly reuse other web specs when discussing common web operations. We currently do this for fetching source maps, but we should also for example do it in resolving sources
  • We should better integrate the x-sourcemap HTTP header in HTML, since it's HTML that is fetching scripts. Ideally, HTML should have a "source map URL" field in script records that is populated by checking the header and/or through our algorithms introduced in Define how to extract the sourceMappingURL comment #94.

I might have more ideas, and I will create individual issues once I think it's time to start going through them. I don't think any of these are blockers for publishing our first version.