Jump to content
Search Community

GSDevTools with npm, Webpack and Vuejs 2.x

AngusSimons 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

Hey folks,

 

I'm trying to setup GSDevTools on a Vuejs using Npm and Webpack.

 

All the plugins are in the folder:

/node_modules/gsap

 

I'm using Vuejs and my component looks like:

<template lang="html">
  <div>
    <div id="animate" @click="animateIt">
      content
    </div>
  </div>
</template>

<script>
  import {TimelineMax, CSSPlugin, Sine, GSDevTools} from 'gsap'

  export default {
    name: 'ComponentName',
    data: () => ({
      var_1: 'dummy'
    }),
    methods: {
      animateIt: function() {
        var t1 = new TimelineMax()
        t1.to('#animate', .2, {
          opacity: 1,
          ease: Sine.easeInOut
        })
          .to('#animate', .2, {
            css: {
              color: red,
            },
            ease: Sine.easeIn
          })
      }
    },
    mounted() {
      GSDevTools.create()
    }
  }
</script>

 

For others plugins they work as expected so i can import them when needed using for example:

import {TimelineMax, CSSPlugin, Sine, Power4} from 'gsap'

 

But if I add the GSDevTools as for the others this doesn't work.

 

If I import the plugin with:

import {GSDevTools} from 'gsap'

// or

import GSDevTools from 'gsap/GSDevTools'

// or 

import GSDevTools from '../../../node_modules/gsap/GSDevTools'

// or 

import * as GSDevTools from '../../../node_modules/gsap/GSDevTools'

// or

var GSDevTools = require ('gsap/GSDevTools')

// or

var GSDevTools = require ('../../../node_modules/gsap/GSDevTools')

 

I got this error:

Quote

[Vue warn]: Error in mounted hook: "TypeError: Cannot read property 'create' of undefined"

 

 

I'm stucked, please Help!!!

Thanks

 

Link to comment
Share on other sites

Short answer:

//assuming you've put the GSDevTools.js file from the bonus-files-for-npm-users folder into your node_modules/gsap folder..
import GSDevTools from 'gsap/GSDevTools';

 

Explanation: GSAP isn't fully written in ES6 yet (working on that). For now, "gsap" simply points to the TweenMax.js file which contains most of the essential classes and plugins, but NOT all of them. GSDevTools is NOT inside of TweenMax - you must load that separately. So when you tried to import it from "gsap" (which, again, points to TweenMax), it didn't find it because it's not exported there. For anything that's not inside TweenMax, you can just import it directly from that folder. Just don't forget to drop all the bonus stuff in there too (from the bonus-files-for-npm-users folder in the zip download). 

 

Make sense? Sorry about any confusion. 

  • Like 1
Link to comment
Share on other sites

6 hours ago, GreenSock said:

Short answer:


//assuming you've put the GSDevTools.js file from the bonus-files-for-npm-users folder into your node_modules/gsap folder..
import GSDevTools from 'gsap/GSDevTools';

 

Explanation: GSAP isn't fully written in ES6 yet (working on that). For now, "gsap" simply points to the TweenMax.js file which contains most of the essential classes and plugins, but NOT all of them. GSDevTools is NOT inside of TweenMax - you must load that separately. So when you tried to import it from "gsap" (which, again, points to TweenMax), it didn't find it because it's not exported there. For anything that's not inside TweenMax, you can just import it directly from that folder. Just don't forget to drop all the bonus stuff in there too (from the bonus-files-for-npm-users folder in the zip download). 

 

Make sense? Sorry about any confusion. 

 

 

Thanks for the reply, no problem for the confusion.

I've tried again importing with  

import GSDevTools from 'gsap/GSDevTools';

 

but got the same error. I've already tried all these possibilities

 

9 hours ago, AngusSimons said:

 


import {GSDevTools} from 'gsap'

// or

import GSDevTools from 'gsap/GSDevTools'

// or 

import GSDevTools from '../../../node_modules/gsap/GSDevTools'

// or 

import * as GSDevTools from '../../../node_modules/gsap/GSDevTools'

// or

var GSDevTools = require ('gsap/GSDevTools')

// or

var GSDevTools = require ('../../../node_modules/gsap/GSDevTools')

 

 

Link to comment
Share on other sites

What do you see when you log this out?

 

console.log(window.com.greensock)

 

 

Make sure you're using the file from the "bonus-files-for-npm-users", and you put it in the root of the folder. Now try importing stuff without a name.

 

import 'gsap';
import 'gsap/GSDevTools';

 

  • Like 1
Link to comment
Share on other sites

Someone else reported a similar issue yesterday and I noticed that their build system wasn't properly handling the "require()" calls inside files, thus the dependencies weren't loading and GSDevTools wasn't defined. I'm not entirely sure how to solve the dependency-loading problem in their build system, so to resolve things in their case I just added two import statements BEFORE the GSDevTools ones, like: 

import TweenMax from "gsap";
import Draggable from "gsap/Draggable";
import GSDevTools from "gsap/GSDevTools";

 

That ensures that GSDevTools has the stuff it needs loaded first (TweenLite, TimelineLite, some Power eases [all of which are in TweenMax], and Draggable).

 

That assumes you dropped the files from the "bonus-files-for-npm-users" (from your membership zip download) into the node_modules/gsap folder, though you could do it in other ways too if you prefer. 

 

Does that resolve things for you? 

  • Like 2
Link to comment
Share on other sites

@GreenSock

 

I see the problem. It's the Draggable code in the GSDevTools file. It either needs to be at the top of the file, or removed completely and added as a dependency.

 

All these import problems can be fixed in the next update with a little work. No need to wait to for v2. Replace all the commonJS and AMD declarations with ES6 imports/exports. Break up the TweenMax file. And make the members download folder a flat directory with all the files, complete with a package.json so it can be easily installed as a local folder or repo. 

 

 

@naaadz and @AngusSimons

 

The easiest thing for now is to probably just edit the GSDevTools file.

 

Find this part of the code on around line 1200...

(function(name) {
	"use strict";
	var getGlobal = function() {
		return (_gsScope.GreenSockGlobals || _gsScope)[name];
	};
	if (typeof(module) !== "undefined" && module.exports) { //node
		require("gsap/TweenLite");
		require("gsap/TimelineLite");
		require("gsap/CSSPlugin");
		module.exports = getGlobal();
	} else if (typeof(define) === "function" && define.amd) { //AMD
		define(["gsap/TweenLite", "gsap/TimelineLite", "gsap/CSSPlugin"], getGlobal);
	}
}("GSDevTools"));

 

 

Add the dependencies for Draggable...

 

(function(name) {
	"use strict";
	var getGlobal = function() {
		return (_gsScope.GreenSockGlobals || _gsScope)[name];
	};
	if (typeof(module) !== "undefined" && module.exports) { //node
		require("gsap/TweenLite");
		require("gsap/TimelineLite");
		require("gsap/CSSPlugin");
		require("gsap/Draggable");
		module.exports = getGlobal();
	} else if (typeof(define) === "function" && define.amd) { //AMD
		define(["gsap/TweenLite", "gsap/TimelineLite", "gsap/CSSPlugin", "gsap/Draggable"], getGlobal);
	}
}("GSDevTools"));

 

 

And then delete everything below it. It should work after that.

 

 

 

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, OSUblake said:

All these import problems can be fixed in the next update with a little work. No need to wait to for v2. Replace all the commonJS and AMD declarations with ES6 imports/exports. Break up the TweenMax file. And make the members download folder a flat directory with all the files, complete with a package.json so it can be easily installed as a local folder or repo. 

 

Thanks Blake! I've got a few concerns, though...

  1. I specifically included Draggable inside GSDevTools so that folks wouldn't have to worry about loading Draggable separately. I realize it's a non-issue in NPM or ES6 when you've got dependency management built-in, though, so I assume you're suggesting a splitting apart of the development files (one for NPM, one for everything else)? 
  2. It sure seems to me like the order of the code inside GSDevTools (Draggable at the bottom instead of the top) shouldn't matter at all because it's already wrapped in some dependency management code that handles things accordingly. The problem seems to be that the build system isn't honoring the require() statements, right? 
  3. If I rework the files so that instead of the CommonJS and AMD declarations, I just use ES6 imports, wouldn't that cause issues with a lot of other (especially older) systems? I must admit it has been a real pain to try to field everyone's requests and have something that works in RequireJS, CommonJS, ES6, Node, Webpack, Browserify, Bower, blah, blah, blah. So as much as I'd love to just simplify to ES6-only, I worry that I'll get innundated with complaints. I could totally be wrong, of course. 
  4. I used to have all the bonus stuff in a flat directory with everything else, and several people complained about that. I'm a little fuzzy right now about all the reasons, but it made sense at the time :) I think maybe it had to do with problems that could arise if someone installs that whole folder locally (not in node_modules) but then they've got some code that is importing directly from "gsap" (in node_modules), and then they'd end up with multiple TweenLite (and other) copies in their bundles. And currently I'm importing from "gsap/FILE" which generally points at the node_modules folder...which would be a BAD thing if the user is installing things locally in a different folder. In other words, I'd have to wire dependencies up differently (relative?)

If you've got a demo of how you think things should be set up, I'd love to see it (or just collaborate with you on how to best structure things). 

 

Link to comment
Share on other sites

 

 

4 hours ago, GreenSock said:

I specifically included Draggable inside GSDevTools so that folks wouldn't have to worry about loading Draggable separately. I realize it's a non-issue in NPM or ES6 when you've got dependency management built-in, though, so I assume you're suggesting a splitting apart of the development files (one for NPM, one for everything else)? 

 

 

Yep. A build process will create all the distributable files that will work with scripts tags, so nothing should be different on that end. I'm not suggesting this for your build process, but one thing I really like about jsDelivr is that you can load any package from npm or github. It doesn't matter if the package has no distributable files, has dependencies on external libraries, or is written is some super future version of JavaScript, it will automatically bundle, compile, and minify everything for you. I'm bringing this up because it should be pretty easy to do, and could even be automated by a CDN if you were super lazy.

 

 

4 hours ago, GreenSock said:

It sure seems to me like the order of the code inside GSDevTools (Draggable at the bottom instead of the top) shouldn't matter at all because it's already wrapped in some dependency management code that handles things accordingly. The problem seems to be that the build system isn't honoring the require() statements, right? 

 

 

I have no idea what's going on there. What's weird is that the first thing I did was move the block of code where you create the exports to the very bottom of the file and it didn't work. It would seem that that should have the same effect as moving the Draggable code to the top of the file. Maybe it's using some type of abstract syntax tree (AST) to trace the code, and knows Draggable is a dependency so it needs to be parsed first. 

http://resources.jointjs.com/demos/javascript-ast

 

 

4 hours ago, GreenSock said:

If I rework the files so that instead of the CommonJS and AMD declarations, I just use ES6 imports, wouldn't that cause issues with a lot of other (especially older) systems? I must admit it has been a real pain to try to field everyone's requests and have something that works in RequireJS, CommonJS, ES6, Node, Webpack, Browserify, Bower, blah, blah, blah. So as much as I'd love to just simplify to ES6-only, I worry that I'll get innundated with complaints. I could totally be wrong, of course. 

 

 

No. ES modules are a real thing, but nobody actually uses them in the browser. ES imports/exports get converted to CommonJS and AMD declarations in the build process, so CommonJS/AMD will be the actual output. Then why do you need to use ES module? Because ES modules are treated differently, and allow for optimizations like tree-shaking. But the big thing I've noticed is that all these CLI tools that people are using for stuff like React, Vue, and Angular treat everything outside of the node_modules folder as an ES module. That's why people have been having trouble importing member plugins from other folders in their project.

 

 

4 hours ago, GreenSock said:

I used to have all the bonus stuff in a flat directory with everything else, and several people complained about that. I'm a little fuzzy right now about all the reasons, but it made sense at the time :) I think maybe it had to do with problems that could arise if someone installs that whole folder locally (not in node_modules) but then they've got some code that is importing directly from "gsap" (in node_modules), and then they'd end up with multiple TweenLite (and other) copies in their bundles. And currently I'm importing from "gsap/FILE" which generally points at the node_modules folder...which would be a BAD thing if the user is installing things locally in a different folder. In other words, I'd have to wire dependencies up differently (relative?)

 

 

The "gsap/FILE" syntax seems to have fixed most of those problems, but you shouldn't have to change anything. You just need to instruct people to install from the folder or a repo instead of the hosted package on npm. Installing from a folder or repo uses what's inside of it as the source, and copies everything to the node_modules folder. It will look and function exactly like the hosted package on npm. I don't think people realize that npm can install from practically any source. You can even symlink folders.

https://docs.npmjs.com/cli/link

 

 

Everything is in my head at the moment, so I don't have a demo, but I have pretty good idea of how this could work.

  • Like 1
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...