Canmove, confirm, emeritus
1,093
edits
Changes
no edit summary
}}
{{FeaturePageBody
|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 open issues 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. When JavaScript gets an error, being able to help the web developer out by showing them where the error occurred in the original source file (PHP script or unminified, still-separate JavaScript for example) would save the developer time every single time they hit an error. The Web Console log messages also include links to the line that generated the log message, so these messages could link back to the original source lines as well. For a long time, there have been [http://altjs.org/ languages that have compiled] to JavaScript, and recently there has been a surge in support for these languages led by [http://coffeescript.com/ CoffeeScript]. CoffeeScript may seem like a fringe language today, but it will soon be shipping with Ruby on Rails 3.1, giving thousands of programmers a reason for developing with something other than JS. When developing an application in CoffeeScript, any time an error is hit the browser tells the user the location of the problem ''in the JavaScript file'', not the source file that the user is working with. [http://weepy.github.com/kaffeine/ One new language] even went so far as to ensure that the lines numbers in the generated JS match up with the lines numbers in the original source file, which is an unfortunate thing to optimize for. The solution to this problem is a mapping from the generated JS to the original source files.|Feature users and use cases=Moderately sophisticated JavaScript developers.}}{{FeatureInfo|Feature priority=P2|Feature roadmap=Developer Tools|Feature list=Desktop|Feature engineering team=DevTools}}{{FeatureTeamStatus|Feature products status=tbd|Feature engineering status=tbd|Feature security status=sec-review-needed|Feature privacy status=tbd|Feature localization status=tbd|Feature accessibility status=tbd|Feature qa status=tbd|Feature ux status=tbd}}== Summary == 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. When JavaScript gets an error, being able to help the web developer out by showing them where the error occurred in the original source file (PHP script or unminified, still-separate JavaScript for example) would save the developer time every single time they hit an error. The Web Console log messages also include links to the line that generated the log message, so these messages could link back to the original source lines as well. For a long time, there have been [http://altjs.org/ languages that have compiled] to JavaScript, and recently there has been a surge in support for these languages led by [http://coffeescript.com/ CoffeeScript]. CoffeeScript may seem like a fringe language today, but it will soon be shipping with Ruby on Rails 3.1, giving thousands of programmers a reason for developing with something other than JS. When developing an application in CoffeeScript, any time an error is hit the browser tells the user the location of the problem ''in the JavaScript file'', not the source file that the user is working with. [http://weepy.github.com/kaffeine/ One new language] even went so far as to ensure that the lines numbers in the generated JS match up with the lines numbers in the original source file, which is an unfortunate thing to optimize for. The solution to this problem is a mapping from the generated JS to the original source files. == Team == * '''Feature Manager''': ''Kevin Dangoor'' (irc: kdangoor)* '''Lead Developer''': ''Nick Fitzgerald'' (irc: fitzgen)* '''Web Console Contact''': ''David Dahl'' (irc: ddahl)* '''SpiderMonkey Contact''': ''Jason Orendorff'' (irc: jorendorff) == Release Requirements == * SpiderMonkey needs to output column in addition to source/line.* 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* Patches for CoffeeScript and UglifyJS will be used to produce examples* A specification for generated scripts to refer to their mappings and a mapping format[[Link title]] == Next Steps & Open Issues =risks=
A security review should be conducted before we have too much technical debt.
* Integration with CoffeeScript.
|Feature overview== Related Bugs & Dependencies ==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. When JavaScript gets an error, being able to help the web developer out by showing them where the error occurred in the original source file (PHP script or unminified, still-separate JavaScript for example) would save the developer time every single time they hit an error. The Web Console log messages also include links to the line that generated the log message, so these messages could link back to the original source lines as well. For a long time, there have been [http://altjs.org/ languages that have compiled] to JavaScript, and recently there has been a surge in support for these languages led by [http://coffeescript.com/ CoffeeScript]. CoffeeScript may seem like a fringe language today, but it will soon be shipping with Ruby on Rails 3.1, giving thousands of programmers a reason for developing with something other than JS. When developing an application in CoffeeScript, any time an error is hit the browser tells the user the location of the problem ''in the JavaScript file'', not the source file that the user is working with. [http://weepy.github.com/kaffeine/ One new language] even went so far as to ensure that the lines numbers in the generated JS match up with the lines numbers in the original source file, which is an unfortunate thing to optimize for.
The solution to this problem is a mapping from the generated JS to the original source files.
|Feature users and use cases=Moderately sophisticated JavaScript developers.
|Feature requirements=* SpiderMonkey needs to output column in addition to source/line.
* 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
* Patches for CoffeeScript and UglifyJS will be used to produce examples
* A specification for generated scripts to refer to their mappings and a mapping format
[[Link title]]
|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 implementation notes=
TBD (status page link)
* 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.
}}__NOTOC__{{FeatureInfo|Feature priority=P2[[Category:Features]]|Feature roadmap=Developer Tools[[Category:Firefox]]|Feature list=Desktop[[Category:|Feature engineering team=DevTools]]}}{{FeatureTeamStatus|Feature products status=tbd|Feature engineering status=tbd|Feature security status=sec-review-needed|Feature privacy status=tbd|Feature localization status=tbd|Feature accessibility status=tbd|Feature qa status=tbd|Feature ux status=tbd}}
