Good news! I was able to expand on what Alex suggested to provide a solution that prevents public variables from being renamed by Google Closure in release builds. A few key points:
- You can set public variables in MXML, and they will work correctly in release builds. Previously, only properties with setters worked in release builds. - I've also determined how to prevent Google Closure from creating multiple copies of static public variables, which caused some values (numbers, boolean, strings) to get out of sync if changed at runtime. This was a closely related issue. - I added prevent-rename-public-symbols and prevent-rename-protected-symbols compiler options. They are true by default, but you can set them to false to go back to the old behavior (which would include reporting a warning for public vars). - No changes were required to the MXMLDescriptor, so my changes won't mess with debugging workflows that require inspecting that data structure at runtime. The process of implementing a better solution for this gave me some ideas related to adding more control over exports, so I plan to give that another try too. Thanks again to Alex for the suggestions that helped make this happen. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > I did a quick test, and I can confirm that a public variable will not be > renamed if a public getter with the same name exists on a different class. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala <joshtynj...@bowlerhat.dev> > wrote: > >> Thanks for the info about Object.defineProperties(). That could be a way >> to provide a workaround that doesn't mess too much with other stuff. >> >> -- >> Josh Tynjala >> Bowler Hat LLC <https://bowlerhat.dev> >> >> >> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui <aha...@adobe.com.invalid> >> wrote: >> >>> >>> >>> On 3/26/20, 12:23 PM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> wrote: >>> >>> We can walk the AST if we have the source code. However, if an MXML >>> class >>> gets compiled into a SWC, I don't think there's a way to figure out >>> which >>> properties are being set in MXML from the definitions alone. When I >>> was >>> investigating some things, I tried the AST walk until I realized >>> that it >>> only worked in my app project, and not with the classes that I was >>> using >>> from framework SWCs. >>> >>> One possibility is that the compiler scans every JS file and looks for >>> the MXMLDescriptor and scans it for strings. Also have to look for the >>> properties array as well. >>> >>> I might actually end up looking at adding an option to convert >>> public vars >>> into getters/setters first. Should be easier than some of the >>> alternatives, >>> which I can dig into more later. >>> >>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming >>> through the entire compilation, not just within the file being visited. In >>> fact, I'm not even sure it has to be Object.defineProperties. It looks >>> like there is some criteria for being a global structure. So to me, it >>> looks like you can prevent a rename, not only by swapping in a legitimate >>> getter/setter for the public var, but also by having some global structure, >>> possibly in an Object.defineProperties attached to the app that defines a >>> bunch of empty properties on some never-to-be-used object and then Closure >>> will not rename those properties on other objects. >>> >>> Of course, I could be wrong, but that's what I think I've seen. I think >>> I saw that including some class with a getter/setter would cause properties >>> in other classes that use the same property name to not be renamed. >>> >>> HTH, >>> -Alex >>> >>> >>>
