[ALOY-220] How to handle uglifyjs alloy-specific changes

GitHub Issuen/a
Resolution Date2012-10-10T02:16:17.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsDocumentation, XML
ReporterTony Lukasavage


We need to determine how we would like to manage the custom changes made to uglifyjs to make it work for alloy. Specifically, a couple of (minimal) changes were needed to facilitate our JSON-derivative tss file format. As it stands now, these changes are simply noted with TODOs in the uglifyjs source code that is part of the alloy project. For the time being, this is OK. if we ever need to update uglifyjs or track our own changes, it becomes a little more difficult to handle. There's a couple ways we can proceed.

Continue to use a specifically marked TODO, perhaps that references this ticket, and re-insert the changes into any new version of uglifyjs. Not ideal, but we may never need to update uglifyjs and this would be the minimum amount of work.

Keep an open ticket or wiki document that keeps track of the uglifyjs changes, just so we have a reference outside of the code itself. Not sure this is entirely necessary or gets us much.

Fork uglifyjs. Make the custom changes in our fork and update from the upstream uglifyjs if necessary. This would be the "best" way to do it, but is likely more work than we should worry about now because as stated before, we may never even need to update uglifyjs

I'm leaning towards #1 for the time being. We can revisit later if we find updating uglifyjs is a reoccurring event. Thoughts?


  1. Russell McMahon 2012-08-28 Let's go with #1 for now. We can revisit in a couple months.
  2. Tony Lukasavage 2012-10-10 We will, for the time being, continue to track our minimal uglifyjs changes via TODOs.

JSON Source