Jump to content
Search Community

Google Closure Compiler

Jan test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi i wounder if someone got TweenMax.js (1.9.4b) minimized with Google's Closure Compiler and ADVANCED_OPTIMIZATIONS.

 

I tried TweenMax.js concated with my animation code and i get an :

'Uncaught TypeError: Cannot read property 'Power4' of undefined' exception at runtime.

If i use SIMPLE_OPTIMAZTIONS everything works fine.

 

Can someone give me a hint? :)

 

Jan

 

 

 

 

 

Link to comment
Share on other sites

Hmm...that definitely looks like a problem in Closure Compiler related to not honoring the order of operation defined in the code. I used to use Closure Compiler, but ran into another really odd issue that [seemingly] caused random errors in Chrome (in a very rare and particular scenario) which is odd because Google makes both Closure Compiler and Chrome! I don't trust it anymore except maybe in simple mode. It's like it tries to get too fancy otherwise and trips over itself. Obviously things work fine in the raw JS and in other minifiers like Uglify (which is what I use now), so I'm pretty sure the problem lies within Closure Compiler itself. 

Link to comment
Share on other sites

  • 3 years later...

I only use TweenLite.js and EasePack.js. When compile, i get 0 warning and 0 error, but when run, it fail. This is my issue, I only use TweenLite.to, TweenLite.from and TweenLite.delayedCall.

Uncaught TypeError: Cannot read property 'Power4' of undefined

It occur in line 166, class TweenLite, this is source

e = create ? _class("easing."+name, null, true) : gs.easing[name] || {};

And this is after compile, k is "Power4", g.Fa is undefined

h = e ? F("easing." + k, null , !0) : g.Fa[k] || {},

This is properties of g, as below, g still have easing property but haven't Fa property.

 

ZznIwgf.png

Link to comment
Share on other sites

Hm. Well, if we know that GSAP works fine on its own, and then you run it through Closure and the "compiled" version breaks, that sure seems like it's an error/problem with Closure, not GSAP, right? How would I know what needs to change in GSAP to prevent Closure from messing things up? 

 

There's a danger in using things like Closure Compiler, much like with SVG "optimizers" because sometimes they make changes the break things. You could, for example, feed in a perfectly valid SVG into SVGO that looks correct in the browser, and if you crank up all the settings to try to make it "optimize" in every possible way, what it spits out might look completely different. That's not the fault of the SVG going in - it's what SVGO is doing to it that's the problem. Similarly, it sounds like Closure Compiler is causing problems here. 

 

I remember years back trying to use Closure Compiler for miniification and it was problematic (literally caused runtime errors). I switched to Uglify which never had a single problem that I've seen. I did some reading back then too and found others who had similar conclusions. Closure Compiler was seen as kinda risky, at least in the advanced mode. 

 

If you've got any specific suggestions for what we'd need to change in GSAP to help Closure Compiler not break things, please do share. Otherwise, I'm at a loss as to how to proceed here, since it sure seems like GSAP isn't the problem. 

  • Like 2
Link to comment
Share on other sites

  • 4 months later...

Just in case someone lands here from google (like I did), I'll answer this question.

 

The reason this is occurring for ADVANCED_OPTIMIZATIONS only is because that mode makes heavy modifications of the source, including renaming of functions and properties that it sees inside your code.  This means unless you declare GSAP as an external source, its going to go ahead and rename all those easings to whatever it pleases.

 

You can see more info on the various ways of insuring this doesn't happen in the docs.

 

A quick fix that I use for individual use cases, rather than entire libraries, is to declare empty objects with the relevant property names and pass those into the compiler as externs, for example;

var Linear = {
    ease: {},
    easeIn: {},
    easeInOut: {},
    easeNone: {},
    easeOut: {},
};

This insures that ADVANCED_OPTIMIZATIONS does not rename those properties in my code base.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...