You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Some missing source maps variants and options in TypeScript compiler #2887
true values disable the inclusion of source map information in the output file.
sourceComments
Type: Boolean Default: false
true enables additional debugging information in the output file as CSS comments
sourceMapContents
Type: Boolean Default: false
true includes the contents in the source map information
sourceMapEmbed
Type: Boolean Default: false
true embeds the source map as a data URI
Notes:
omitSourceMapUrl sounds crazy, but there really are use cases when you want the transpiler to generate .map file while ignoring the sourceMappingURI in JS.
With sourceComments, it does not generate the real, cryptic source-maps, but instead put a comment on each line like /* Line: _, Column:_, File:_ */ in generated code pointing to the source file. Turning on this option has no effect on regular source-map; both options can be enabled and hence the map file produced also keep the line comments into consideration (both can be generated in parallel with little trickery, as you can preemptively determine where the debug comments will appear).
sourceMapContents: this embeds contents of all source (.ts) files in .map as contents array. The order of this array corresponds to sources array.
sourceMapEmbed: compiler generates the source-maps in-memory and instead of stamping out to .map file, it applies the base64 text encoding and append it as a value of sourceMappingURI.
omitSourceMapUrl sounds crazy, but there really are use cases
What are some of those use cases?
sourceComments [... puts] a comment on each line like /* Line: _, Column:_, File:_ */
While this is an interesting suggestion, it springs two questions:
We may emit nodes that span multiple lines to a single line; how would this be dealt with?
Why do users need this feature?
When do users find the sourcemaps coming short that they need to resort to this?
TypeScript is generally so close to the emitted JavaScript that I've always found myself able to easily Ctrl+F/⌘+F to find corresponding portions of a file, so does this buy users that much?
sourceMapContents: this embeds contents of all source (.ts) files in .map as contents array.
Actually, sourceMapContents might also be part of #2484 (i.e. the inlineSources option) - Mohamed Hegazy (@mhegazy), can you comment? If so, maybe we should call it sourceMapContents instead of inlineSources.
With sourceComments, it does not generate the real, cryptic source-maps, but instead put a comment on each line like /* Line: , Column:, File:_ */ in generated code pointing to the source file. Turning on this option has no effect on regular source-map; both options can be enabled and hence the map file produced also keep the line comments into consideration (both can be generated in parallel with little trickery, as you can preemptively determine where the debug comments will appear).
I think this is not so useful anymore both for the SASS and TS project. It was a hack to support "source map" in browsers, before source map got standardized and used widely.
omitSourceMapUrl sounds crazy, but there really are use cases when you want the transpiler to generate .map file while ignoring the sourceMappingURI in JS.
I guess the use case here is by supporting referencing by HTTP header X-SourceMap: /path/to/file.js.map?
Let's all take it easy - I think we can agree that everybody here has quality in mind for TypeScript. 😄
sourceMapContents and sourceMapEmbed are planned, so we see the justification in that. Hopefully that'll be in our master branch soon.
I'm still not personally sold on sourceComments. This is analogous to requesting that a compiler emit assembly/IL with comments for corresponding lines of code because the debugger file format isn't understandable. Sure, it's great to get a sense of what the compiler is doing, but the utility of it falls short outside of mild curiosity - especially given that TypeScript tends to emit code that is canonical JavaScript, so your output should look decently readable anyway.
I'm admittedly on the fence on omitSourceMapUrl. I'd like to hear from Mohamed Hegazy (@mhegazy) about it.
regarding omitSourceMapURL i am still not clear about the value of adding this option. the web essential scenario you list above is better achieved using the compiler API to generate these. i think this is what you want to do generally. I will have to see more compelling scenarios to be convinced.
as for, sourceComments, we will have to decline this request. We put a lot of effort to make sure the output code is similar to the input as much as possible. This has been one of the TypeScript axioms from the beginning and still is. Even with renamed variables or generate temporary names, the compiler bases them on user defined variables to make sure the generate .js code is readable and recognizable. For debugging, TypeScript has supported source maps since 0.8 time. and almost all browsers and developer tools do support them as well; so i do not see the need for yet another form of mapping.
@jasonwilliams200OK I'm trying to have a meaningful discussion :).
Also you know that those comments where invented because there weren't anyway to map compiled CSS code to the original SASS code. Then, developers saw a huge demand for source map and almost every source map vendor adopted it. So in other words, source map deprecates those comments.
Activity
DanielRosenwasser commentedon Apr 23, 2015
What are some of those use cases?
While this is an interesting suggestion, it springs two questions:
This sounds interesting; when is this handy?
I believe this is being covered in #2484.
DanielRosenwasser commentedon Apr 23, 2015
Actually,
sourceMapContentsmight also be part of #2484 (i.e. theinlineSourcesoption) - Mohamed Hegazy (@mhegazy), can you comment? If so, maybe we should call itsourceMapContentsinstead ofinlineSources.tinganho commentedon Apr 23, 2015
I think this is not so useful anymore both for the SASS and TS project. It was a hack to support "source map" in browsers, before source map got standardized and used widely.
I guess the use case here is by supporting referencing by HTTP header
X-SourceMap: /path/to/file.js.map?mhegazy commentedon Apr 23, 2015
sourceMapEmbed is also covered by #2484.
mhegazy commentedon Apr 23, 2015
sourceComments --> how would u uses this?
DanielRosenwasser commentedon Apr 23, 2015
Interesting; here's the relevant part of the spec:
Are there any actual advantages between one or the other though?
tinganho commentedon Apr 23, 2015
Daniel Rosenwasser (@DanielRosenwasser) I can't see any advantages.
DanielRosenwasser commentedon Apr 24, 2015
Let's all take it easy - I think we can agree that everybody here has quality in mind for TypeScript. 😄
sourceMapContentsandsourceMapEmbedare planned, so we see the justification in that. Hopefully that'll be in ourmasterbranch soon.I'm still not personally sold on
sourceComments. This is analogous to requesting that a compiler emit assembly/IL with comments for corresponding lines of code because the debugger file format isn't understandable. Sure, it's great to get a sense of what the compiler is doing, but the utility of it falls short outside of mild curiosity - especially given that TypeScript tends to emit code that is canonical JavaScript, so your output should look decently readable anyway.I'm admittedly on the fence on
omitSourceMapUrl. I'd like to hear from Mohamed Hegazy (@mhegazy) about it.mhegazy commentedon Apr 24, 2015
regarding omitSourceMapURL i am still not clear about the value of adding this option. the web essential scenario you list above is better achieved using the compiler API to generate these. i think this is what you want to do generally. I will have to see more compelling scenarios to be convinced.
as for, sourceComments, we will have to decline this request. We put a lot of effort to make sure the output code is similar to the input as much as possible. This has been one of the TypeScript axioms from the beginning and still is. Even with renamed variables or generate temporary names, the compiler bases them on user defined variables to make sure the generate .js code is readable and recognizable. For debugging, TypeScript has supported source maps since 0.8 time. and almost all browsers and developer tools do support them as well; so i do not see the need for yet another form of mapping.
mhegazy commentedon Apr 24, 2015
that is a different request then.. you want a comment with the original file name when using --out. is this accurate?
mhegazy commentedon Apr 24, 2015
Still not convinced :)
tinganho commentedon Apr 24, 2015
@jasonwilliams200OK I'm trying to have a meaningful discussion :).
Also you know that those comments where invented because there weren't anyway to map compiled CSS code to the original SASS code. Then, developers saw a huge demand for source map and almost every source map vendor adopted it. So in other words, source map deprecates those comments.