Yishay came across this post: https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option <https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option>
I wonder if there’s some way to use the property_map options to control renaming. My guess is that it would only work if @export is not used. Related to this general topic: I realized that goog is much better at minifying functions than properties. That makes sense because you can reliably point to functions using references. Referencing variables is not reliable because the references can end up pointing to different values. Theoretically, getters and setters could be better for that. The problem is that goog treats the getters like variables. If the compiler would rewrite getter and setter access to the underlying getter and setter functions, goog could probably do a better job optimizing those. (i.e. instead of foo.baz = “baz”, Falcon could write foo.set__baz(“baz”) and var baz = foo.baz could become var baz = foo.get__baz()) Harbs > On Aug 7, 2017, at 9:56 AM, Harbs <harbs.li...@gmail.com> wrote: > > Another case which seems to need exports is any property used in MXML. > > It seems like the low hanging fruit would be to allow some kind of markup to > specify classes which don’t need exports. > > Rewriting constants to literals is another one which should be pretty easy to > solve. > >> On Aug 7, 2017, at 9:24 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> Dynamic access (aka square bracket access) is used in data binding, but >> people use it for other things as well. The really hard case involves >> "string math" where you access something like foo[someValue + "label"]. >> It is hard to know that "enUSLabel" and "frFRLabel" should not be renamed. >> >> And yes, modules will need to find APIs in other modules or the host and >> renaming is a problem there too. >> >> But I'll bet that only a small fraction of APIs should not be renamed in >> any typical app, especially if no modules are in play. The question is >> "which ones"? But if we can make it possible, it should be a good >> obfuscator as well. >> >> My 2 cents, >> -Alex >> >> On 8/6/17, 10:57 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> I’m fuzzy on all the reasons for using @import so much. >>> >>> We’ve had discussions on the topic, but hey were spread out. >>> >>> The reasons that stick in my mind was for bracketed access (needed for >>> binding?) and reflection. Another reason I think that was mentioned was >>> for modules (which we don't’ yet really have a way to use). >>> >>> Is that it? >>> >>>> On Aug 7, 2017, at 8:34 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >>>> >>>> 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 >>>> >>> >> >
