DevTools/Features/SourceMap: Difference between revisions

no edit summary
No edit summary
No edit summary
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=SourceMap
|Feature name=SourceMap
|Feature stage=Planning
|Feature stage=Landed
|Feature status=In progress
|Feature status=In progress
|Feature version=23
|Feature health=OK
|Feature health=OK
|Feature status note=Initial support landed in Firefox 23. Improvements coming down the pipe as always.
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Kevin Dangoor
|Feature feature manager=Dave Camp
|Feature feature manager=Kevin Dangoor
|Feature lead engineer=Nick Fitzgerald
|Feature lead engineer=Nick Fitzgerald
|Feature qa lead=Vlad Maniac
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature open issues and risks=A security review should be conducted before we have too much technical debt.
Now that there is an evolving spec for the source map file format, the first
step is to write the core libraries to generate and consume/query source
maps. These core libraries should be very general and reusable, so the plan
right is to use the Common JS AMD format.
Next, a patch should be written for the web console to support mapping logged
messages and uncaught errors back to their original source. It is still
undecided, from an API/architecure point of view, who will check whether a given
script has an associated source map, and how they will notify the potential
consumer of the source map that it exists or mark the script as having an
associated source map. This issue will rise to the surface at this stage.
As time progresses, and dependencies are met (or not), the order of the
following still needs to be decided:
* Integration with the debugger.
* Integration with UglifyJS.
* Integration with CoffeeScript.
|Feature overview=Nearly every web developer starts with JavaScript in one form during development and then produces JavaScript in another form for production use. Most often, this is a case of joining files together and minifying the output to reduce the number of requests the browser needs to make and how much data the browser needs to transfer. Another example of JavaScript starting in one form and ending up in the final form used by the browser is in PHP scripts which will sometimes generate bits of JavaScript as they generate their pages.
|Feature overview=Nearly every web developer starts with JavaScript in one form during development and then produces JavaScript in another form for production use. Most often, this is a case of joining files together and minifying the output to reduce the number of requests the browser needs to make and how much data the browser needs to transfer. Another example of JavaScript starting in one form and ending up in the final form used by the browser is in PHP scripts which will sometimes generate bits of JavaScript as they generate their pages.


Line 46: Line 26:
A user can take .js source files and compress them with the Closure Compiler. Errors and log messages in the Web Console will refer to the original .js files.
A user can take .js source files and compress them with the Closure Compiler. Errors and log messages in the Web Console will refer to the original .js files.


Case 2: CoffeeScript
Case 2: Languages which compile to JavaScript
 
You can start with a .coffee file. Any log output or errors generated will refer back to the original .coffee file, rather than the generated .js file.
 


You can start with an original file which contains any language that compiles to JS (for example, CoffeeScript). Any logged output or uncaught errors will refer back to the original file, rather than the generated JS file which is actually being executed.
|Feature requirements=* When a sourcemap is available, error messages in console will link to the original source, not the generated JS
|Feature requirements=* When a sourcemap is available, error messages in console will link to the original source, not the generated JS
* Likewise, console log output will link back to the original source
* Likewise, console log output will link back to the original source
Line 57: Line 35:
* A specification for generated scripts to refer to their mappings and a mapping format
* A specification for generated scripts to refer to their mappings and a mapping format
* SpiderMonkey needs to output column in addition to source/line.
* SpiderMonkey needs to output column in addition to source/line.
 
* code that is loaded via eval() should also support sourcemaps
|Feature non-goals=* Ideally, the source mapping file will also work for mapping LESS and similar to CSS. However, implementing the user interface for style source mapping is out of scope for this particular feature.
|Feature non-goals=* Ideally, the source mapping file will also work for mapping LESS and similar to CSS. However, implementing the user interface for style source mapping is out of scope for this particular feature.
* It is possible to have a chain of source maps. Consider the case of a .coffee file that is compiled to .js and run through Closure Compiler. The final source map would refer to lines in the compiled JS, which would have a separate source map referring to lines in the .coffee file. For the first crack at this feature, we will not bother with that case.
* It is possible to have a chain of source maps. Consider the case of a .coffee file that is compiled to .js and run through Closure Compiler. The final source map would refer to lines in the compiled JS, which would have a separate source map referring to lines in the .coffee file. For the first crack at this feature, we will not bother with that case.
* console.trace does not need to be supported in the initial version
|Feature functional spec=I've written a web app called "Social Socialer Socialest". It's going to make me rich. I spent all morning creating it.
|Feature functional spec=I've written a web app called "Social Socialer Socialest". It's going to make me rich. I spent all morning creating it.


Line 81: Line 60:


When I hover over the link to the source files, I should be presented with a link to the .js file that the browser executed as well.
When I hover over the link to the source files, I should be presented with a link to the .js file that the browser executed as well.
|Feature ux design=[[File:SourceMapInConsole.png|Source mapped output in the Web Console]]
|Feature implementation notes=TBD (status page link)


* {{bug|669999}} - Add a library for parsing and consuming source map files to Firefox


* {{bug|670002}} - Use source maps in the web console
=== Note about source map loading ===


* [https://bugzilla.mozilla.org/show_bug.cgi?id=568142 Bug 568142: Expand source notes to carry column information] - Bug to add line/col information to be available to debuggers.
When an error is first generated, the source maps have not yet been loaded. That means that the Web Console cannot immediately display the mapped error info. Once an error is hit, however, the map should be loaded and the error message should be updated as soon as possible to contain the mapped info.
 
|Feature ux design=[[File:SourceMapInConsole.png|Source mapped output in the Web Console]]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=618650 Bug 618650: map JS source coordinates to source language that was translated to JS]
|Feature implementation notes=* {{bug|771597}} - Source maps + debugger meta bug
 
* [https://bugzilla.mozilla.org/show_bug.cgi?id=626932 Bug 626932: Shrink JSParseNode] - Would add character-offset to SpiderMonkey (as opposed to line/col).
** Has an incomplete patch by njn. Doesn't compile.
 
* David Flanagan has been working on adding "//@line ###" style comment support to SpiderMonkey which is being tracked by [https://bugzilla.mozilla.org/show_bug.cgi?id=663934 this bug].
 
 
[https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit The source map file format spec originally proposed by Google]. I (fitzgen) have edit permissions and am working with them on making something we can all agree upon.
 
This feature is related to the [[Script_Origin_Tracking|Script Origin Tracking proposal]], because the mapping should be able to accommodate the many ways in which JavaScript can come into existence on a page.
 
 
* Brendan and Jim Blandy have suggested that using a separate mapping file will work better than including the mapping in the generated source.


* A [https://bugs.webkit.org/show_bug.cgi?id=60550 bug with a patch] was opened for WebKit but closed INVALID.
[https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit The source map file format specification]
** Webkit has [https://bugs.webkit.org/show_bug.cgi?id=30933 another bug] open for this feature.
** A new [https://bugs.webkit.org/show_bug.cgi?id=63940 bug with a patch] was opened.
}}
}}
{{FeatureInfo
{{FeatureInfo
|Feature priority=P2
|Feature priority=P3
|Feature rank=3
|Feature roadmap=Developer Tools
|Feature roadmap=Developer Tools
|Feature list=Desktop
|Feature list=Desktop
Line 116: Line 78:
}}
}}
{{FeatureTeamStatus
{{FeatureTeamStatus
|Feature security status=sec-review-sch
|Feature security status=sec-review-complete
|Feature security notes=sched 2011.08.24
|Feature security health=OK
|Feature security notes=Complete: 2011.08.24 [[Security/Reviews/Firefox9/ReviewNotes/SourceMap|Notes]]
}}
}}
Confirmed users
125

edits