Future-proof "Scopes" encoding

[szuend]

@jridgewell and I brainstormed a bit how we could make the "Scopes" encoding forward compatible without making it too complex or heavy handed. I'll implement some of these in the coming days to get some numbers to compare.

Future-proof "Scopes" encoding

The current "Scopes" encoding is not ideal w.r.t. to future extension:

• Adding new fields to OriginalScope and GeneratedRange in a backwards compatible way is impossible. Any tool implementing the current proposal would break once we add new optional fields to either data structure.

• The encoding uses the , and ; characters on top of base64 encoded VLQ numbers. Moving to a future binary source map format will require a different encoding for "Scopes" to account for , and ;.

We should aim for an encoding that is both forwards-compatible and is purely VLQ based: So the only difference between the current JSON source map format and a potential future binary format is how VLQs are encoded.

The crux of the issue is to find the right balance between

• retaining some flexibility for future extensions without going overboard (e.g DWARF-style encoding),
• encoding/decoding complexity,
• and encoded size.

This sourcemap-scopes-encoding repository proposes some potential "Scopes" encodings that keep both goals in mind while aiming for a healthy balance.

[szuend]

I moved the various encoding schemes to a separate repository: https://github.com/ChromeDevTools/sourcemap-scopes-encoding

The repo has implementations, some example source maps and a small runner that compares the encoding schemes.