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 >
