Source Map

License

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Introduction

This document is a draft version of a hardened version of the Source Map v3 specification. In its current form, it’s not a defined standard and is subject to modifications. If you want to get involved you will find more information under the following GitHub repositories:

• Spec Repository: holds the different specifications (v1, v2, v3 and the hardened v3 draft you are looking at)

• RFC Repository: meta repository for change suggestions to the specification.

1. Background

The original source map format (v1) was created by Joseph Schorr for use by Closure Inspector to enable source-level debugging of optimized JavaScript code (although the format itself is language agnostic). However, as the size of the projects using the source maps expanded the verbosity of the format started to become a problem. The v2 ([V2Format]) was created by trading some simplicity and flexibility to reduce the overall size of the source map. Even with the changes made with the v2 version of the format, the source map file size was limiting its usefulness. The v3 format is based on suggestions made by Pavel Podivilov (Google).

This document codifies the prior art that is Source Map v3 but is more specific about the precise meanings of the specification.

2. Terminology

Generated Code is the code which is generated by the compiler or transpiler.

Original Source is the source code which has not been passed through the compiler.

Base64 VLQ: [VLQ] is a [base64] value, where the most significant bit (the 6th bit) is used as the continuation bit, and the "digits" are encoded into the string least significant first, and where the least significant bit of the first digit is used as the sign bit.

Note: The values that can be represented by the VLQ Base64 encoded are limited to 32-bit quantities until some use case for larger values is presented.

Source Mapping URL refers to the URL referencing the location of a source map from the Generated code.

3. General Goals

The goals for the v3 format of Source Maps

• Reduce the overall size to improve parse time, memory consumption, and download time.

• Support source-level debugging allowing bidirectional mapping

• Support server-side stack trace deobfuscation

4. Source Map Format

The source map is a JSON document containing a top-level JSON object with the following structure:

{
  "version" : 3,
  "file": "out.js",
  "sourceRoot": "",
  "sources": ["foo.js", "bar.js"],
  "sourcesContent": [null, null],
  "names": ["src", "maps", "are", "fun"],
  "mappings": "A,AAAB;;ABCDE"
  "ignoreList": [0]
}

Note: The previous specification suggested an order to the keys in this file, but for practical reasons, the order cannot be defined in many JSON generators and has never been enforced.

version is the version field which must always be the number 3 as an integer. The source map may be rejected in case of a value different from 3.

file an optional name of the generated code that this source map is associated with. It’s not specified if this can be a URL, relative path name, or just a base name. As such it has a mostly informal character.

sourceRoot 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.

sources is a list of original sources used by the mappings entry. Each entry is either a string that is a (potentially relative) URL or null if the source name is not known.

sourcesContent an optional list of source content (that is the Original Source), useful when the "source" can’t be hosted. The contents are listed in the same order as the sources. null may be used if some original sources should be retrieved by name.

names a list of symbol names used by the mappings entry.

mappings a string with the encoded mapping data (see § 4.1 Mappings Structure).

ignoreList an optional list of indices of files that should be considered third party code, such as framework code or bundler-generated code. This allows developer tools to avoid code that developers likely don’t want to see or step through, without requiring developers to configure this beforehand. It refers to the sources array and lists the indices of all the known third-party sources in the source map. Some browsers may also use the deprecated x_google_ignoreList field if ignoreList is not present.

4.1. Mappings Structure

The mappings data is broken down as follows:

• each group representing a line in the generated file is separated by a semicolon (;)

• each segment is separated by a comma (,)

• each segment is made up of 1, 4, or 5 variable length fields.

The fields in each segment are:

1. The zero-based starting column of the line in the generated code that the segment represents. If this is the first field of the first segment, or the first segment following a new generated line (;), then this field holds the whole Base64 VLQ. Otherwise, this field contains a Base64 VLQ that is relative to the previous occurrence of this field. Note that this is different than the fields below because the previous value is reset after every generated line.

2. If present, a zero-based index into the sources list. This field is a Base64 VLQ relative to the previous occurrence of this field, unless this is the first occurrence of this field, in which case the whole value is represented.

3. If present, the zero-based starting line in the original source is represented. This field is a Base64 VLQ relative to the previous occurrence of this field, unless this is the first occurrence of this field, in which case the whole value is represented. Always present if there is a source field.

4. If present, the zero-based starting column of the line in the source represented. This field is a Base64 VLQ relative to the previous occurrence of this field unless this is the first occurrence of this field, in which case the whole value is represented. Always present if there is a source field.

5. If present, the zero-based index into the names list associated with this segment. This field is a base 64 VLQ relative to the previous occurrence of this field unless this is the first occurrence of this field, in which case the whole value is represented.

Note: This encoding reduces the source map size by 50% relative to the V2 format in tests performed using Google Calendar.

4.2. Resolving Sources

If the sources are not absolute URLs after prepending the sourceRoot, the sources are resolved relative to the SourceMap (like resolving the script src attribute in an HTML document).

4.3. Extensions

Source map consumers must ignore any additional unrecognized properties, rather than causing the source map to be rejected, so that additional features can be added to this format without breaking existing users.

4.4. Notes on File Offsets

Using file offsets was considered but rejected in favor of using line/column data to avoid becoming misaligned with the original due to platform-specific line endings.

5. Index Map

To support concatenating generated code and other common post-processing, an alternate representation of a map is supported:

{
  "version" : 3,
  "file": "app.js",
  "sections": [
    {
      "offset": {"line": 0, "column": 0},
      "map": {
        "version" : 3,
        "file": "section.js",
        "sources": ["foo.js", "bar.js"],
        "names": ["src", "maps", "are", "fun"],
        "mappings": "AAAA,E;;ABCDE"
      }
    },
    {
      "offset": {"line": 100, "column": 10},
      "map": {
        "version" : 3,
        "file": "another_section.js",
        "sources": ["more.js"],
        "names": ["more", "is", "better"],
        "mappings": "AAAA,E;AACA,C;ABCDE"
      }
    }
  ]
}

The index map follows the form of the standard map. Like the regular source map, the file format is JSON with a top-level object. It shares the version and file field from the regular source map, but gains a new sections field.

sections is an array of JSON objects that itself has two fields offset and map.

5.1. Section

offset is an object with two fields, line and column, that represent the offset into generated code that the referenced source map represents.

map is an embedded complete source map object. An embedded map does not inherit any values from the containing index map.

The sections must be sorted by starting position and the represented sections may not overlap.

6. Conventions

The following conventions should be followed when working with source maps or when generating them.

6.1. Source Map Naming

Optionally, a source map will have the same name as the generated file but with a .map extension. For example, for page.js a source map named page.js.map would be generated.

6.2. Linking generated code to source maps

While the source map format is intended to be language and platform agnostic, it is useful to have some conventions for the expected use-case of web server-hosted JavaScript.

There are two suggested ways to link source maps to the output. The first requires server support in order to add an HTTP header and the second requires an annotation in the source.

The HTTP header should supply the source map URL reference as:

sourcemap: <url>

Note: Previous revisions of this document recommended a header name of x-sourcemap. This is now deprecated; sourcemap is now expected.

The generated code should include a line at the end of the source, with the following form:

//# sourceMappingURL=<url>

Note: The prefix for this annotation was initially //@ however this conflicts with Internet Explorer’s Conditional Compilation and was changed to //#. Source map generators must only emit //# while source map consumers must accept both //@ and //#.

Note: //@ is needed for compatibility with some existing legacy source maps.

This recommendation works well for JavaScript, but it is expected that other source files will have different conventions. For instance, for CSS /*# sourceMappingURL=<url> */ is proposed. On the WebAssembly side, such a URL is encoded using [WasmNamesBinaryFormat], and it’s placed as the content of the custom section ([WasmCustomSection]) named sourceMappingURL.

<url> is a URL as defined in [URL]; in particular, characters outside the set permitted to appear in URIs must be percent-encoded and it may be a data URI. Using a data URI along with sourcesContent allows for a completely self-contained source map.

Regardless of the method used to retrieve the Source Mapping URL the same process is used to resolve it, which is as follows:

When the Source Mapping URL is not absolute, then it is relative to the generated code’s source origin. The source origin is determined by one of the following cases:

• If the generated source is not associated with a script element that has a src attribute and there exists a //# sourceURL comment in the generated code, that comment should be used to determine the source origin. Note: Previously, this was //@ sourceURL, as with //@ sourceMappingURL, it is reasonable to accept both but //# is preferred.

• If the generated code is associated with a script element and the script element has a src attribute, the src attribute of the script element will be the source origin.

• If the generated code is associated with a script element and the script element does not have a src attribute, then the source origin will be the page’s origin.

• If the generated code is being evaluated as a string with the eval() function or via new Function(), then the source origin will be the page’s origin.

6.3. Linking eval’d code to named generated code

There is an existing convention that should be supported for the use of source maps with eval’d code, it has the following form:

//# sourceURL=foo.js

It is described in [EvalSourceURL].

7. Language Neutral Stack Mapping Notes

Stack tracing mapping without knowledge of the source language is not covered by this document.

8. Multi-level Mapping Notes

It is getting more common to have tools generate sources from some DSL (templates) or compile TypeScript -> JavaScript -> minified JavaScript, resulting in multiple translations before the final source map is created. This problem can be handled in one of two ways. The easy but lossy way is to ignore the intermediate steps in the process for the purposes of debugging, the source location information from the translation is either ignored (the intermediate translation is considered the “Original Source”) or the source location information is carried through (the intermediate translation hidden). The more complete way is to support multiple levels of mapping: if the Original Source also has a source map reference, the user is given the choice of using that as well.

However, It is unclear what a "source map reference" looks like in anything other than JavaScript. More specifically, what a source map reference looks like in a language that doesn’t support JavaScript-style single-line comments.

9. Fetching Source Maps

To fetch a source map given a URL url, run the following steps:

1. Let promise be a new promise.

2. Let request be a new request whose URL is url.

3. Fetch request with processResponseConsumeBody set to the following steps given response response and null, failure, or a byte sequence bodyBytes:

   1. If bodyBytes is null or failure, reject promise with a TypeError and abort these steps.

   2. If url’s scheme is an HTTP(S) scheme and bodyBytes starts with `)]}'`, then:

      1. While bodyBytes’s length is not 0 and bodyBytes’s 0th byte is not an HTTP newline byte:

         1. remove the 0th byte from bodyBytes.

         Note: For historic reasons, when delivering source maps over HTTP(S), servers may prepend a line starting with the string )]}' to the source map.

         )]}'garbage here
         {"version": 3, ...}
         

         is interpreted as

         {"version": 3, ...}
         

   3. Let sourceMap be the result of parsing JSON bytes to a JavaScript value given bodyBytes.

   4. If the previous step threw an error, reject promise with that error.

   5. Otherwise, resolve promise with sourceMap.

4. Return promise.