[ALOY-274] Improve optimizer.js code and testing
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Resolved |
Resolution | Fixed |
Resolution Date | 2012-11-15T16:12:15.000+0000 |
Affected Version/s | 2012 Sprint 19 |
Fix Version/s | Alloy 0.3.2, 2012 Sprint 23 |
Components | XML |
Labels | n/a |
Reporter | Tony Lukasavage |
Assignee | Unknown |
Created | 2012-09-17T08:19:19.000+0000 |
Updated | 2018-03-07T22:26:16.000+0000 |
Description
The original issue that pointed to the need for revisiting the optimizer.js code was ALOY-273, a very difficult to debug issue reported by a developer. In light of the optimizer's minimal impact on code and the fact that it has more than once made valid JS parse as invalid, it has been disabled.
We need to evaluate whether the optimizer.js code is necessary, and if its rewards outweigh its risks. A few failing test cases exist in the optimizer.js now that would need to be resolved before it could be re-enabled, but when they are resolved, should it be re-enabled? What other potential test cases could we be missing that will break otherwise valid JS? Is it worth a few compile time optimizations to potentially create hard to debug issues with valid JS in the future?
We need to determine if more judicious use of uglifyjs should be enforced, perhaps only using it for managing our TSS format and providing our compile time directives (OS_IOS, ENV_DEV, etc...).
optimizer.js is now far more stable. This is a result of a major simplification of the optimizer.js code in combination with allowing uglifyjs to remove dead code based on string to string comparisons. All tests pass, including new ones designed to test all the existing known edge cases. The commit(s) can be seen here: * refactored code: ** https://github.com/appcelerator/alloy/commit/bcaffef93fada754103f4e1b8927133bb41f250a ** https://github.com/appcelerator/alloy/commit/a2e3294d6ab695b9a2f44d229f969a7fd9933453