source map support #19

Closed
dylang opened this Issue Mar 29, 2013 · 14 comments

Projects

None yet

9 participants

dylang commented Mar 29, 2013

It would be helpful to generate a source map so that when debugging in Chrome we'll see the original line numbers.

A source map can be passed to Uglify so that the compressed code can also be debugged with original line numbers and variables.

t0mas commented May 22, 2013

+1, this would be helpful in combination with the "sourceMapIn" option from Uglify

Owner
btford commented May 30, 2013

Sounds good; charted this for the 0.4.1 release. See milestones for details.

llwt commented Jun 29, 2013

Another +1 for this. Any ETA? 0.4.1 is past due on the milestones.

Owner
btford commented Jun 29, 2013

Looked at source maps some more; not convinced that this is useful anymore.

You will almost certainly be passing this along to a minifier. Unless the minifier takes intermediate source maps into account, the final source map post minification will be broken.

Owner
btford commented Jun 29, 2013

also updated the milestone

Minifiers accept input source maps

llwt commented Jun 29, 2013

The use case I would be implementing would be with grunt/uglify.

See the "sourceMapIn" param:
https://github.com/gruntjs/grunt-contrib-uglify#sourcemapin

t0mas commented Jul 1, 2013

My usecase is the same as Steven's, making sure all (grunt) tools in the chain produce a sourceMap and use the previous map as an input.

Soviut commented Jul 22, 2013

+1 for sourcemap chaining in grunt.

Unless the minifier takes intermediate source maps into account, the final source map post minification will be broken.

Uglify does accept intermediate source maps: https://github.com/mishoo/UglifyJS2#the-simple-way

caitp commented Sep 18, 2013

After helping debug some code today which badly needed source maps, I think I'm happy to take a stab at writing this patch -- work is already in progress.

Owner
btford commented Sep 18, 2013

@caitp thanks!

caitp commented Sep 19, 2013

@btford I'm not too familiar with the architecture of Astral, but it doesn't seem unreasonable to have Astral leverage source-map, and have a flow like this:

  1. Astral accepts an optional input sourcemap, as well as an optional output sourcemap.
    • If input sourcemap is available, create a SourceMapConsumer
    • If output sourcemap is available, create a SourceMapGenerator
  2. For each block of AST
    • Provide interface for passes to transform the source map. If no transformation occurs for a given AST block, then re-use the source mapping.
    • If a transformation does occur, SourceMapGenerator.addMapping to transform the output sourcemap
  3. After each pass
    • Move output sourcemap into input sourcemap position, and create a new output SourceMapGenerator
  4. After all passes have been completed
    • If an output pass is available, write it to a file

So this should theoretically provide a nice interface for any Astral application to generate sourcemaps (and leverage sourcemap chaining) in a uniform way.

If anyone has any thoughts on this, or suggestions on a better way to build this, I'm all ears. But yeah, without integrating this into Astral itself, I'm not totally sure how this would work.


Alternatively, a separate module like astral-sourcemap could be provided which does all this stuff, and Astral could allow it to work as a sort of plugin, by providing callbacks to be executed beforeRun, afterRun, and afterPass. This would keep things a bit more modular I guess.


Attempt #1 So, as I mention in the commit message (and above), it's not totally clear if this is an appropriate method for doing this, and it's only my guess based on the documentation whether it will even work correctly or not.

If anyone interested in this would care to review this patch, that would be awesome. It may not be the right approach, but it seems like it's on the right track.


Okay, I don't think Attempt #1 is the right way to go, so closing that... Stuff in #51 should work a lot better.

@nichtich nichtich referenced this issue in btford/grunt-ngmin Apr 24, 2014
Closed

Support for source maps #15

Collaborator

Please try https://github.com/olov/ng-annotate. ngmin is now deprecated: #93

If your issue isn't resolved there please open an issue at https://github.com/olov/ng-annotate/issues

If you really want ngmin to fix this issue, feel free to fork it and use that.

@eddiemonge eddiemonge closed this Aug 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment