It might be more interesting and fruitful to investigate removing @export annotations. How could we determine which variables are being accessed via foo[someProperty] and only keep @export on those properties?
You might be able to use a text replacement tool to remove @export and mess around with the rest of the source to prevent renaming of the few variables that will be looked up by foo[someProperty]. Either keeping the @export or use ["string"] access which I think prevents renaming in GCC. There are options in the compiler to skip generating the js-debug and just call GCC. My 2 cents, -Alex On 8/6/17, 3:13 PM, "Harbs" <harbs.li...@gmail.com> wrote: >I’m getting close to the release of my app and I’m starting to think >about some things related. > >I would like to have the option for minified code to have package, class >and members renamed at compile time. I have two reasons for this: > >1. Obfuscation. As it stands, it’s pretty easy to take minified code from >FlexJS and reconstruct the original code with the original structure and >naming. Everything is @exported and easily readable. I’d like to have a >method to rename everything to something completely unintelligible. > >2. Code size. I was not sure how much package paths would effect code >size, so I just did an experiment. I renamed every package path in my app >to a much shorter version (i.e. org.apache.flex.core becomes fxc, etc.) I >did not spend the time renaming class names or class member names. Just >shortening the package paths resulted in a reduction of 509KB to 505KB >after gzipping. (Prior to gzipping the reduction was 53 KB.) Class names >and member names are a significant percentage of the remaining code, so >it stands to reason that renaming those will result in a further >reduction of code size. > >To be clear: obfuscation is a much bigger drive for me than code size. >Code size is just an added plus. > >I was thinking of ideas on how to accomplish this goal. > >One idea was to enable some kind of metadata (or comments) in the code >that the compiler could interpret to rewrite the names > >Another idea was some kind of mapping file that serves the same purpose. > >This is something that should be enabled via a compiler option. > >The challenge would be with library code in a swc. Since it’s already >compiled to JS, it would be much harder to rename things unless it would >work using find/replace. It seems to me that it would be more reliable if >done while walking the tree and packages, classes and members could each >be handled explicitly. > >Thoughts? > >Harbs
