Skip to content

Some missing source maps variants and options in TypeScript compiler #2887

Closed

Description

Please consider the following in your on going efforts:

From node-sass readme https://github.com/sass/node-sass/#sourcecomments:

omitSourceMapUrl

Type: Boolean Default: false

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.

Activity

  1. DanielRosenwasser commented on Apr 23, 2015

    @DanielRosenwasser
    Member

    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.

    This sounds interesting; when is this handy?

    sourceMapEmbed

    I believe this is being covered in #2484.

  2. DanielRosenwasser commented on Apr 23, 2015

    @DanielRosenwasser
    Member

    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.

  3. tinganho commented on Apr 23, 2015

    @tinganho
    Contributor

    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?

  4. mhegazy commented on Apr 23, 2015

    @mhegazy
    Contributor

    sourceMapEmbed is also covered by #2484.

  5. mhegazy commented on Apr 23, 2015

    @mhegazy
    Contributor

    sourceComments --> how would u uses this?

  6. DanielRosenwasser commented on Apr 23, 2015

    @DanielRosenwasser
    Member

    I guess the use case here is by supporting referencing by HTTP header X-SourceMap

    Interesting; here's the relevant part of the spec:

    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.

    Are there any actual advantages between one or the other though?

  7. tinganho commented on Apr 23, 2015

    @tinganho
    Contributor

    Daniel Rosenwasser (@DanielRosenwasser) I can't see any advantages.

  8. DanielRosenwasser commented on Apr 24, 2015

    @DanielRosenwasser
    Member

    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.

  9. mhegazy commented on Apr 24, 2015

    @mhegazy
    Contributor

    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.

  10. mhegazy commented on Apr 24, 2015

    @mhegazy
    Contributor

    that is a different request then.. you want a comment with the original file name when using --out. is this accurate?

  11. mhegazy commented on Apr 24, 2015

    @mhegazy
    Contributor

    Still not convinced :)

  12. tinganho commented on Apr 24, 2015

    @tinganho
    Contributor

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

  13. added
    DeclinedThe issue was declined as something which matches the TypeScript vision
    Out of ScopeThis idea sits outside of the TypeScript language design constraints
    on Dec 9, 2015
  14. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DeclinedThe issue was declined as something which matches the TypeScript visionOut of ScopeThis idea sits outside of the TypeScript language design constraintsSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions