Jump to content
Search Community

No _gsTransform after build using 'gsap/all' imports?

Friebel 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

Moving an existing es6 animation project from Webpack 3 to Webpack 4 I'm facing a weird phenomenon according to the _gsTransform object when I move from 'gsap' to 'gsap/all' imports. Maybe it's the very high temperature here at the moment, but I can't really get my head around why this is...

At the moment unfortunately I can't find the time to create a small project to show you guys, but if I can find the time later on I'll setup one. If I can't fix this with 'gsap/all' I'll stick with 'gsap' on this project for now and fix it later, but it would be great if maybe by chance anybody faced the same problem and could point me in a direction.

 

The thing is that by running the webpack development server on the project everything works like it always did. Also when I move all greensock imports from 'gsap' to 'gsap/all'. But as soon as I let webpack create a production build and run the build from the dist on my local server, suddenly it won't run because the _gsTransform object I use to get a position of an svg-element is not there anymore, so it can't read x and y from it. 

 

At first I thought it could be the treeshaking thing which could be different between development and production. So I included all gsap modules I use in a constant, like the examples on the greensock website. So like:

import { TweenLite, TimelineMax, Linear, Sine, Back } from 'gsap/all';

const uses = [TweenLite, TimelineMax, Linear, Sine, Back]; 

 

But to my surprise that didn't solve the issue: the _gsTransform object just isn't there on the DOM/SVG-element on the production build. Which is there and working fine when running a development build and running from there, or running from webpack-dev-server.

 

I know webpack 4 does some things differently when mode is set to production, but I can't find a reason that something could cause to prevent the _gsTransform to be on the svg-element on production builds. 

 

I also switched off uglifyjs and all, so this cannot be some strange renaming thing.

 

In the end I even made both development and production using the exact same stripped config, but still only the development build works and has the _gsTransform object.

 

To me this doesn't make any sense so far and I'm out of ideas now. Anybody here perhaps knows if there is something extra I need to do, or maybe import from 'gsap/all' to make _gsTransform work and available on production builds?

 

To be clear: using imports from 'gsap' everything works on production builds too, the problem is only there when importing from 'gsap/all'. It seems like some needed part of greensock is not make it after treeshaking and I needed to import something extra from the lib which I didn't needed to import before, when I was importing from 'gsap' (and the full package came with it, because there was no treeshaking). But even then I think it's strange that the development build doesn't have this problem with 'gsap/all'... crazy

 

Again, if I can't find some solution today I will stick on this project on 'gsap', so it's not a grand big of a deal, but I'd rather switch.

 

Thanks!

Link to comment
Share on other sites

1 minute ago, GreenSock said:

All the CSS-related wizardry comes from CSSPlugin. I bet Webpack is tree shaking it out of your bundle because you didn't reference it anywhere. 

 

Yes!! That was it. Thanks for the quick response @GreenSock Jack!

 

So I guess that means Webpack is not using treeshaking during development, so you can only tell after a production build if everything survives treeshaking... that's kind of scary, but good to know now!

 

Glad it works! Thanks again Jack!

  • Like 2
Link to comment
Share on other sites

  • 4 months later...

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...