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,

On 8/6/17, 3:13 PM, "Harbs" <> 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.

Reply via email to