Sorry to hear. :-( I still wonder if maybe we can document all the cases where we’re relying on not renaming and find a way to deal with those cases. (for someone who wants to disable exports)
I know Greg has done a significant amount of digging related to his reflection work. Alex, do you have any thoughts? Harbs > On Mar 25, 2020, at 9:06 PM, Josh Tynjala <[email protected]> wrote: > > (With credit to Chris for the subject name 😏) > > Some of you may know that over the last 2-3 months I've been looking into > ways to add more control over how the compiler handles renaming and > exporting APIs in the generated JS. Ideally, my work would have culminated > in a variety of options that would allow release builds to be much smaller, > if you were willing to sacrifice certain capabilities (things along the > lines of dynamic access of properties and reflection). Obviously, you would > have been able to keep things working the same as they do today, so my > changes would have been opt-in. > > I've determined that Closure does not actually expose the ability to > prevent renaming of JS APIs, except by exporting them. The advanced > compiler APIs that Closure exposes to prevent renaming are specifically > intended for compiling multiple related projects together (like we're doing > with modules). Additionally, I discovered that Closure does not guarantee > that any custom rename mappings will be respected. In fact, the > documentation says they may be completely ignored, and there is official > guidance that says not to do what I was originally trying to do. I could > not find any other Closure compiler APIs accessible in Java that could do > what we want here, so I think that our original assumption that preventing > renaming programmatically would be possible was incorrect. > > In the case of disabling exports, I found that there are parts of the > Royale framework that rely on the fact that properties are exported. > Bindings and setting properties in MXML are the most visible. There are > probably more that I didn't discover yet because the first two had such a > big impact. Honestly, I am not experienced enough in the framework side of > Royale to know that I won't break anything if I try to start making changes > to ensure that all framework code can handle property renaming. Maybe > disabling exports is still possible, but I don't think that I'm the one who > can do it. > > In the end, I was left feeling extremely frustrated with Closure compiler > once again. It's not the first time, and it's unlikely to be the last. I > wasted two whole months trying to follow its incredibly strict rule system. > In the past, I have tried to fight Closure instead, so I thought that I was > doing things right this time. I really wish I would have spent that time > doing something else that would have benefitted Royale more. > > Side note: As I was reverting the rename/export changes I had made to the > compiler, I realized that there were some issues with my previous attempts > to improve the situation with warn-public-vars. With that in mind, I > reverted those changes too (for now). I plan to look into a better solution > for warn-public-vars soon, but I can't guarantee that anything will work > because it's another place where Closure compiler is the cause of the issue. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev>
