We added //@line n "f" as a magic comment which, when JSOPTION_ATLINE is set, should cause the next line to be taken as line n of the file named "f". This seems to have been regressed by recent scanner changes, but I'll file that separately. The idea here is to relieve the source-to-JS translator from having to spew such comments all over the place in generated JS. Instead, the generated JS would set an ideally more concise mapping up using, e.g., JSON. This was proposed by Jeremy Ashkenas at http://intertwingly.net/blog/2010/11/25/Hobgoblin-of-Little-Minds#c1292138238. /be

See bug 618652 for an @line bug with patch and test (I hope it can be a Firefox 4 ride-along, since it is not a blocker). /be

In case my @line ref might mislead, source coordinates must be finer grained than lines in our minified world. Line and column, as jimb has planned already. /be

Mark Miller cited http://blog.csdn.net/dollyn/archive/2009/09/01/4506156.aspx#sourcemapfile just now. Syntax aside, the idea lines up with this bug. /be

So, SourceMap Format-ish, in terms of the data model, but in say JSON format? Guess someone can start hacking away at a document describing that. Thoughts on how to link the SMAP file/data to the final generated source? - comment at the bottom of the generated source points to a URL of the SMAP file - SMAP data included literally as a comment in the generated file - debugger loads the file using a path-math operation of the JS file URL (remove trailing ".js" if there, append ".smap")

(In reply to comment #4) > - SMAP data included literally as a comment in the generated file I'm not a fan of inlining the mapping data because this same source mapping protocol is going to be used to debug minified code as well as "transpiled" sources. Because of that, it makes sense to have the mapping data be located in a separate file, to keep the js file sizes as small as possible. I think either of the other two options would be feasible, and don't have a strong opinion either way at this time.

Can anyone point to any other SMAP-like stories for debug? I'm hesitant to even look at the JSR 45 stuff; the link Brendan pointed to in comment #3 appears to be a copy of the JSR 45 specification. The "original" JSR 45 spec requires a click-through agreement to read, from the jcp site itself. Would prefer to look at something "cleaner".

(In reply to comment #6) > Can anyone point to any other SMAP-like stories for debug? You could look at the way that Closure Compiler generates source maps. See the src/com/google/debugging/sourcemap directory in the source code.

https://docs.google.com/document/d/14AWiLDDxEuLaWuyG0X6deLRufrvxRu8HBP0LNJwvRZw/edit?hl=en_US&pli=1 https://bugs.webkit.org/show_bug.cgi?id=63940 is moving. /be

Chrome 18 has sourcemap support - http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

GWT 2.5 plugin-free debugger Super Dev Mode relies on Source Maps: https://developers.google.com/web-toolkit/articles/superdevmode

Is this bug still valid?

Echoing Florian ^ Is this bug still valid?

Yeah, we've been done here for years. For specific bugs related to source mapping, file bugs that block https://bugzilla.mozilla.org/show_bug.cgi?id=dbg-sourcemap.