After upgrading from 1.18.2 to 1.19.0 got a requireJS error for TweenLite

[Wix Wow!Team 2 Likes (Newbie)]

TL;DR

I upgraded our project to use 1.19.0 after using 1.18.2 and requirejs couldn't find TweenLite unless I defined it explicitly in the require config paths object.

Is it the expected behavior?

 

 

 

We do amd with requirejs.

My GSAP section in the paths object looks like this (there is also a base url defined of our external libs server):

paths: {
            //  ...
            TweenMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},
            TimelineMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},
            ScrollToPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/ScrollToPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/ScrollToPlugin')},
            DrawSVGPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/DrawSVGPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/DrawSVGPlugin')},
            // ...
}

This setup worked for a long time now without changing anything but version numbers up until 1.18.2.

After changing the paths to 1.19.0 I got a console error by reuirejs saying it got 404 on TweenLite because it tried to load it from localhost -

require.min.js:34   GET http://localhost/TweenLite.js 

The way to overcome it was to add a line in paths for TweenLite too

TweenLite: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},

Is it an expected behavior? Is it a bug? Am I missing something in the require config?

 

Thanks.

Tom.

[GreenSock 8,117 Likes (Superhero)]

Hey Tom. Actually, in version 1.18.5 (which I know you weren't using, but...) we switched to a relative path (like "./TweenLite" or "../TweenLite") for better compatibility with Webpack but then promptly heard from some RequireJS folks who said that made it **much** harder for them, so in 1.19.0 we switched back to simply "TweenLite" which should be simple enough to accommodate in the config of any of the tools (RequireJS, Webpack, whatever). In other words, in terms of the define() statements I'm pretty sure 1.18.2 and 1.19.0 are identical. Well, except that we did add a define() call in ScrollToPlugin that requires TweenLite whereas previously there was no such statement but you already needed to have TweenLite defined anyway if you were loading things like TimelineMax (and I see that you were). 

 

You're saying everything is working fine once you added the TweenLite path, right? 

[Wix Wow!Team 2 Likes (Newbie)]

Thanks Jack.

For your question - yes, once I add TweenLite to the paths of my require config looks like everything works fine.

[Wix Wow!Team 2 Likes (Newbie)]

Apologies for bumping the issue,

Just need to know - Jack, are you planning on addressing this? or do you consider it an acceptable behavior?

Should I wait for another version?

[GreenSock 8,117 Likes (Superhero)]

I'm a little confused - we provided a solution, but are you asking if at some point in the future you'll be able to remove the path from your config? Adding that path seems like a pretty bullet-proof solution, but as we move toward ES6 it may become unnecessary. The problem is that a full ES6 port isn't a magic bullet either, and poses its own problems. For example, we're hyper-focused on performance and we've seen that ES6 transpilers often introduce painful runtime slowdowns and can bloat files too. 

 

It's a bit frustrating because there are many, many different build systems that people are using these days and they all have their own quirks and requirements. When people come to us with a problem, they're usually only looking at it through the lens of their particular build system and might wonder why we don't just slap a fix in there, but it's just not that simple. As evidenced above, the "fix" for one, might break in a different build system. Pretty much every build system allows you to define specific paths if you need to (like in the config file), so that seems like a pretty reasonable thing to do here. But again, we're hoping to move toward ES6 and hopefully figure out how to keep things from slowing down or bloating the files. Thanks for your patience!