Input source maps

[rtm]

Suggestion

Support input source maps, for the case where a TS file is generated programatically from some other source file, in order to permit end-to-end mapping.

Such source maps could either be specified in the .ts file using the //# SourceMappingURL=foo.ts.map notation, searched for under the name *.ts.map, or found in-line in the .ts sources, etc., depending on various options.

The effect would be that the *.js.map file generated (or inlined) would be the equivalent of what is known as "applying" the input source map to the tsc-generated sourcemap. In other words, the sourcemap would map lines in the *.js file all the way back to the original file(s) from which the *.ts file was generated.

Use Cases

This issue has come up in the context of some literate programming hacking I am doing. The programmer works on "literate programming documents" (actually, a flavor of Markdown), and then "tangles" (to use Knuth's terminology) that into a TS file.

My tangler generates the *.ts.map file. Currently, what I am doing is to provide an extra utility which the programmer can use to "apply" the map I create to the one created by tsc to get lines in the *.js all the way back to the literate programming document. However, this is a bit clumsy, and requires some setup. It would be nicer if tsc could take in source maps, apply them itself, and output *.js.map files reflecting that mapping.

Examples

Currently, the user does something like the following:

modernlit --sourcemap foo.lit.md # creates foo.ts and foo.ts.map
tsc --sourcemap foo.ts # creates foo.js and foo.js.map
mlsourcemap foo.ts.map foo.js.map # rewrites foo.js.map by "applying" foo.ts.map

("modernlit" is the name I am currently using for my literate programming system.)

With the feature I am proposing, the call to mlsourcemap could be eliminated. tsc would find foo.ts.map, and perform the mapping, generating a foo.js.map which reflected it having been "applied" to the JS-to-TS sourcemap. This would avoid the user having to remember to call mlsourcemap, and avoid me having to write it, maintain, and document it.

For information on "applying" (remapping) sourcemaps, as implemented in the Mozilla source-maps library, see here.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)