[ALOY-261] Re-evaluate use of uglifyjs vs. code-processor
| GitHub Issue | n/a |
|---|---|
| Type | Story |
| Priority | Medium |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2012-11-14T16:49:01.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | XML |
| Labels | n/a |
| Reporter | Tony Lukasavage |
| Assignee | Tony Lukasavage |
| Created | 2012-09-12T12:20:44.000+0000 |
| Updated | 2014-02-04T00:34:49.000+0000 |
Description
With a need for source mapping and other features that may not be readily available for us in uglifyjs, and the desire to use less external technologies, we should consider the code-processor project for our AST parsing, compiler conditionals, etc... for Alloy.
Will need to have discussion with Bryan to see if code-processor covers our necessary list of features, and if it will making true debugging of alloy apps, in alloy code, easier than if we tried to do it with uglifyjs v2.
the code-processor is a more generic means of processing javascript. Alloy's use of uglifyjs for things like compiler directives and code generation are very specific to Alloy. For this reason, Alloy will continue to do its own processing using uglifyjs. In the future, though, it may be possible to use the code-processor as a supplement to Alloy specific processing. If this is desired, a new ticket will be created in the future to account for it.