DevTools/Features/SourceMap: Difference between revisions

Jump to navigation Jump to search

DevTools/Features/SourceMap (view source)

Revision as of 19:22, 7 July 2011

3,377 bytes removed ,  7 July 2011
→‎Next Steps & Open Issues
Line 45: Line 45:
== Next Steps & Open Issues ==
== Next Steps & Open Issues ==


* Decide if starting off without columns from SpiderMonkey is enough of a win to pursue this at this time
A security review should be conducted before we have too much technical debt.


* How is the browser notified that a source map exists for a given script?
Now that there is an evolving spec for the source map file format, the first
** Should it be a comment at the top of the source? Something like //@sourceMap=http://example.com/path/to/source/map
step is to write the core libraries to generate and consume/query source
*** This could work with "eval" and script tag injection.
maps. These core libraries should be very general and reusable, so the plan
*** John J Barton has suggested that it is best to put 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.
right is to use the Common JS AMD format.
** Should it be an attribute on the script's tag? Something like <script src='/path/to/foo.js' data-source-map='path/to/foo.smap'>
*** This would not work with eval, but would work with script tag injection.
** Should it just 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", the source map 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 the source map does not exist.
** 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 a source map?</strike>
Next, a patch should be written for the web console to support mapping logged
** <strike>Should the JavaScript engine be in debug-mode?</strike>
messages and uncaught errors back to their original source. It is still
** <strike>Should a flag or preference be set?</strike>
undecided, from an API/architecure point of view, who will check whether a given
** <strike>Should the console/firebug/debugger/etc have to flip a switch explicitly when they are started and flip it back off again when they exit?</strike>
script has an associated source map, and how they will notify the potential
** John J Barton points out that the browser shouldn't be handling the fetching of source maps, the tool which is consuming them should (such as the debugger).
consumer of the source map that it exists or mark the script as having an
*** This neatly side-steps the above issues because if the tool isn't on, it won't ever fetch the source map.
associated source map. This issue will rise to the surface at this stage.


* When should the <strike>browser</strike> debugger fetch the source map?
As time progresses, and dependencies are met (or not), the order of the
** As soon as it knows of the existence of the source map?
following still needs to be decided:
** <strike>By the time a message is logged, or an exception is thrown, it is already too late to fetch the source map because we do not want to delay displaying a message while we go fetch 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 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.


* When (if at all) should the <strike>browser</strike> debugger fetch the original source file[s] referenced from a source map?
* Integration with the debugger.
** 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?
* Integration with CoffeeScript.
** 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. 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.


== Related Bugs & Dependencies ==
== Related Bugs & Dependencies ==
Fitzgen
Confirmed users
125

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/326471"

Navigation menu