For kicks I tried modifying the compiler to not emit @export for my code (it
still has the @exports for SDK code).
The result on code size was more than 50KB smaller AFTER gzipping. That’s a
reduction of more than 10%. Pretty significant. That’s without any class
renaming.
Anyway, it blew up my app on properties that were used in data binding in MXML.
I didn’t fix that to see the next place it blew up.
If we go this route, we probably need to make MXML output smarter…
> On Aug 10, 2017, at 12:31 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> I've seen GCC not track renames before. The Object.defineProperty is just
> a data structure and doesn't add to the set of APIs for a class definition.
>
> I just realized that the class names are used by SimpleCSSValuesImpl to
> determine the type selectors. So if you rename those strings you will
> have to change your CSS.
>
> Also, I have not removed the exportSymbol calls on each class yet. I will
> try that as well.
>
> -Alex
>
>
> On 8/9/17, 2:11 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>
>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>
>>> The change I just made should only be for MXML. But I think I saw that
>>> I
>>> never did remove the @export for getters and setters in AS. However,
>>> doing so would probably break MXML setting of those properties.
>>>
>>> I don't think you can tell when compiling a SWC which properties someone
>>> is going to use from MXML, so I'm not sure passing through @export or
>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>
>> It would be useful for client code because I do know which properties my
>> MXML will use.
>>
>>> On
>>> the other hand, MXML does know every property that you accessed from
>>> MXML
>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>> you
>>> can tell it things that shouldn't be renamed.
>>
>> That sounds interesting.
>>
>>> IMO, this is a bug or missing capability in GCC. They don't see
>>> Object.defineProperties as part of the class definition so they don't
>>> track the renames properly. So, removing @exports from getters in AS
>>> may
>>> also just fail in calls from other AS classes.
>>
>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>
>>> Regarding obfuscation, if we have to export getters, is that really
>>> exposing important secrets?
>>
>> Not sure, but I’d like to keep the code as difficult to follow as
>> possible.
>>
>>> The actual code for a getter/setter is
>>> elsewhere in the output file. It might be possible to do string
>>> replacement on the exported names after the minification.
>>
>> String replacement is definitely an option if it comes to that. I’m
>> probably going to do that for class names and paths as I don’t really see
>> that we currently have a solution for that.
>>
>>> Thoughts?
>>> -Alex
>>>
>>> On 8/9/17, 1:24 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>
>>>> I just compiled with the new option and it appears to work. Yay. On the
>>>> other hand, only functions and variables are being minified. getters
>>>> and
>>>> setters (which is a very large percentage of the signature of my code)
>>>> is
>>>> not.
>>>>
>>>> It looks like that adds the @exports for non-mxml files as well. Can we
>>>> output the @exports for only MXML declared variables?
>>>>
>>>> If a comment with @export is added in AS code, will that be passed
>>>> through to the JS output?
>>>>
>>>> If yes, I think @exporting ids declared in MXML should be the only case
>>>> we need. I can probably handle any specific cases where that might
>>>> break
>>>> output code by manually inserting @export statements.
>>>>
>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>> @export. See if that works for you and then see if you think there is
>>>>> enough obfuscation.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 8/9/17, 12:45 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>
>>>>>> The problem is as follows:
>>>>>>
>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>> following:
>>>>>> textInput: {
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> get: function() {
>>>>>> return this.textInput_;
>>>>>> },
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> set: function(value) {
>>>>>> if (value != this.textInput_) {
>>>>>> this.textInput_ = value;
>>>>>>
>>>>>>
>>>>>>
>>>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdat
>>>>>> eE
>>>>>> ve
>>>>>> nt(this, 'textInput', null, value));
>>>>>> }
>>>>>> }
>>>>>> },
>>>>>>
>>>>>> which gets minified to this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatc
>>>>>> hE
>>>>>> ve
>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>
>>>>>> goog has no way of knowing that the original textInput property name
>>>>>> is
>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>
>>>>>> I think the solution to this is to add @export tags to the
>>>>>> Object.defineProperty specification for any property that’s declared
>>>>>> or
>>>>>> used in the MXML.
>>>>>>
>>>>>> If localId is used, there might be another option which would be to
>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>> pretty
>>>>>> sure that goog will not rename really short property names like that.
>>>>>> (We
>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <harbs.li...@gmail.com> wrote:
>>>>>>>
>>>>>>> Here’s a problem I ran into:
>>>>>>>
>>>>>>> I have a component which has the following:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>>> e.
>>>>>>> ap
>>>>>>>
>>>>>>>
>>>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7C
>>>>>>> fa
>>>>>>> 7b
>>>>>>>
>>>>>>>
>>>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaam
>>>>>>> WR
>>>>>>> Ac
>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas
>>>>>>> te
>>>>>>> .a
>>>>>>>
>>>>>>>
>>>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7
>>>>>>> Cf
>>>>>>> a7
>>>>>>>
>>>>>>>
>>>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaa
>>>>>>> mW
>>>>>>> RA
>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>
>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>> etc.
>>>>>>>
>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>> etc.,
>>>>>>> but every reference to these properties is renamed.
>>>>>>>
>>>>>>> textInput.addEventListener
>>>>>>> becomes:
>>>>>>> this.yw.addEventListener
>>>>>>>
>>>>>>> disableBead.disabled
>>>>>>> becomes
>>>>>>> this.Jm.disabled
>>>>>>>
>>>>>>> etc.
>>>>>>>
>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.li...@gmail.com
>>>>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> I’ll give it a go and see.
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>>>>>> <mailto:aha...@adobe.com.INVALID>> wrote:
>>>>>>>>>
>>>>>>>>> I don't think getters and setters get renamed because they are
>>>>>>>>> keys
>>>>>>>>> in the
>>>>>>>>> Object.defineProperties data structure. I'm wondering if that
>>>>>>>>> will
>>>>>>>>> be
>>>>>>>>> enough obfuscation for you or not.
>>>>>>>>>
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>> On 8/8/17, 10:22 PM, "Harbs" <harbs.li...@gmail.com
>>>>>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>> I have a custom component “A” which implements a DisabledBead in
>>>>>>>>>> ActionScript. It has a getter called “enabled”.
>>>>>>>>>>
>>>>>>>>>> I have another MXML file “B” which uses the component and
>>>>>>>>>> specifies
>>>>>>>>>> enabled=“false”.
>>>>>>>>>>
>>>>>>>>>> I’m assuming the “enabled” property in “A” will be renamed
>>>>>>>>>> without
>>>>>>>>>> an
>>>>>>>>>> @export.
>>>>>>>>>>
>>>>>>>>>> The mxml in “B” will still be using a string for the property
>>>>>>>>>> name
>>>>>>>>>> which
>>>>>>>>>> will be “enabled” that will be undefined.
>>>>>>>>>>
>>>>>>>>>>> On Aug 9, 2017, at 7:55 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>>>>>>>> <mailto:aha...@adobe.com.INVALID>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I just tried DataBindingExample. MyInitialView is essentially a
>>>>>>>>>>> custom
>>>>>>>>>>> component. What are you thinking won't work?
>>>>>>>>>>>
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 8/8/17, 2:30 PM, "Harbs" <harbs.li...@gmail.com
>>>>>>>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Did you try MXML with custom components? I’m not sure I
>>>>>>>>>>>> understand
>>>>>>>>>>>> how
>>>>>>>>>>>> that would work.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 9, 2017, at 12:01 AM, Alex Harui
>>>>>>>>>>>>> <aha...@adobe.com.INVALID
>>>>>>>>>>>>> <mailto:aha...@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some things I found were that MXML isn't a problem because the
>>>>>>>>>>>>> id
>>>>>>>>>>>>> maps
>>>>>>>>>>>>> to
>>>>>>>>>>>>> a getter/setter which maps to Object.DefineProperty which
>>>>>>>>>>>>> takes
>>>>>>>>>>>>> an
>>>>>>>>>>>>> object
>>>>>>>>>>>>> structure where the ids are keys so they don't get renamed.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
