Changes

* How Now that there is an evolving spec for the browser notified that a source map exists for a given script?** Should it be a comment at file format, the top of the source? Something like //@sourceMap=http://example.com/path/to/source/map*** This could work with "eval" and script tag injection.first*** John J Barton has suggested that it step is best to put write the comment at the bottom of a script so that it can be dynamically added without shifting the existing line numbers for a script. I (fitzgen) agree with him.** Should it be an attribute on the script's tag? Something like <script src='/path/core libraries togenerate and consume/foo.js' data-query source-map='path/to/foo.smap'>*** This would not work with eval, but would work with script tag injectionmaps.** Should it just These core libraries should be implicit that the source map file is a replacement of the suffix of the script's file? For example, if a script's URL is "foo.js"very general and reusable, so the source map planright is implied to be at "foo.smap"?*** This would not work with eval, but would work with script tag injection.*** This would result in unnecessary HTTP requests when use the source map does not existCommon JS AMD format.** What is th URL pointing to the source map relative to?*** The script itself, or the page loading the script?

* <strike>What requirements must be satisfied before the browser fetches Next, a source map?</strike>** <strike>Should the JavaScript engine patch should be in debug-mode?</strike>** <strike>Should a flag or preference be set?</strike>** <strike>Should written for the web console/firebug/debugger/etc have to flip a switch explicitly when they are started support mapping loggedmessages and flip it uncaught errors back off again when they exit?<to their original source. It is stillundecided, from an API/strike>architecure point of view, who will check whether a given** John J Barton points out that the browser shouldn't be handling the fetching of script has an associated source mapsmap, and how they will notify the tool which is consuming them should (such as the debugger).potential*** This neatly side-steps consumer of the above issues because if the tool isn't on, source map that it won't ever fetch exists or mark the script as having anassociated source map. This issue will rise to the surface at this stage.

* When should the <strike>browser</strike> debugger fetch the source map?** As soon as it knows of the existence of the source map?** <strike>By the time a message is loggedprogresses, and dependencies are met (or an exception is thrownnot), it is already too late to fetch the source map because we do not want to delay displaying a message while we go fetch order of the source map.</strike>*** Incorrect. John J Barton points out that a typical web apps log hundreds of messages and most of them are ignored. We can hold off fetching the source map until the user first requests it by trying following still needs to display more information about a particular logged message or error thrown. Until that point in time, the source map information is useless because in all likelihood the user isn't even looking at it.be decided:

* When (if at all) should Integration with the <strike>browser</strike> debugger fetch the original source file[s] referenced from a source map?** As soon as it has retrieved the source map?** John J Barton suggests that it should be delayed as long as possible and only the files which are needed by the user be fetched. Most likely, the user is going to be debugging ~40 or so lines of code, we don't want to fetch all thousands and thousands of lines of code from a large, un-minified app.

* From an API standpoint, how should the browser tell the JS debugger that a source map has been fetched and is available?Integration with UglifyJS.

* Where are the original source files referenced from the source map?** Presumably, they are URLs; what are they relative to?*** The origin of the script?*** The origin of the page?*** I would assume they are relative to the source map (this is what Closure's file format does) * Where can source maps be located? Do we want to let script's say they come from any arbitrary place?** Should they be restricted to the same origin as their script?** Should they be restricted to the same origin as the webpage?** From either of the above? * How should the composition of source maps be handled? (e.g. Integration with CoffeeScript -> js -> minified js -> concatted with other js files)** Should this be the responsibility of the debugger to traverse the source mappings, or should it be assumed that they are composed on the server side?*** If it is the responsibility of the debugger to traverse the source mappings by hand, then we should list other source map files in the first source map file so that they can all be downloaded in parallel and we don't have to follow a long list of links to other source map files one at a time.