The problem is that some output might look like this:
bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. qName: “bar.Foo” };
And the minifier will rename qName in the output differently in the main app vs
the module:
In the main app:
bar.Foo..prototype.ROYALE_CLASS_INFO = { name: “Foo”. a: “bar.Foo” };
In a module:
bar.Baz..prototype.ROYALE_CLASS_INFO = { name: “Baz”. c: “bar.Baz” };
Code that accesses someObj.ROYALE_CLASS_INFO.qName in the main app will do:
Var qName = someObj.ROYALE_CLASS_INFO.a;
And that won’t work for objects in the module that are using ‘c’ for QName.
If you turn on -js-dynamic-access-unknown-members when building the SWCs, then
these patterns in the SWC will look like:
bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. ‘qName’: “bar.Foo” };
But then every user of the SWC will never get qName renamed, which wastes
bytes. So I think we want to not use -js-dynamic-access-unknown-members when
building SWCs.
So the -prevent-rename-object-keys option I added is only turned on for certain
keys when building a module or a main app that loads a module. For the simple
Module example, we only needed to prevent renaming of the following keys:
cssData, _bindings, ROYALE_CLASS_INFO, superClass_, qName
The Royale compiler copies JS files from the SWCs to bin/js-debug. What this
option does is filter each file as it is copied, modifying the code for the
keys. We’re already scanning every line in those files anyway in
GoogDepsWriter. That way folks not building apps with modules get maximum
renaming and only those needing to prevent renaming in their output can prevent
that renaming.
We’ll see if that holds up well for Roman. There was some additional hacking
in the compiler since superclass_ is in base.js and not in our SWCs, so that
file and key was special cased. Will there be more? Also I special cased
Language.is/as/closure as they are not unknown members but are not exported and
can be renamed in most apps but need to not be renamed for module and apps
loading modules.
You might find it useful to shave off a few bytes in your app where you don’t
really want ALL unknown members to not be renamed. This option can let you
specify just the list of members that matter.
HTH,
-Alex
From: Harbs <harbs.li...@gmail.com>
Reply-To: "users@royale.apache.org" <users@royale.apache.org>
Date: Wednesday, January 12, 2022 at 2:13 PM
To: "users@royale.apache.org" <users@royale.apache.org>
Subject: Re: Compiling Modules (was Re: Load time is very slow)
Didn’t totally grok what you said.
Can you give a practical difference in when it would be used?
On Jan 12, 2022, at 7:39 PM, Alex Harui
<aha...@adobe.com<mailto:aha...@adobe.com>> wrote:
The option I added takes a list of members and post-processes. I think all
other options change what is output during the compilation and
-js-dynamic-access-unknown-members doesn’t take a list of members.
-Alex
From: Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>>
Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>"
<users@royale.apache.org<mailto:users@royale.apache.org>>
Date: Wednesday, January 12, 2022 at 2:30 AM
To: "users@royale.apache.org<mailto:users@royale.apache.org>"
<users@royale.apache.org<mailto:users@royale.apache.org>>
Subject: Re: Compiling Modules (was Re: Load time is very slow)
How is this different than -js-dynamic-access-unknown-members?
On Jan 12, 2022, at 10:04 AM, Alex Harui
<aha...@adobe.com<mailto:aha...@adobe.com>> wrote:
I added a -prevent-rename-object-keys compiler option that works as a
post-processor. It scans the js files being copied into bin/js-debug and adds
quotes around things.
