v1.19.1 throws error on TimelineLite

[jptinsman]

My project is using gsap and noticed that when using 1.19.1 we get a TimelineLite is not defined error. We originally built the project on ^1.17.0 using Bower. Our pre-prod environment is using 1.19.0 and works fine; however, when we deployed to prod yesterday we got that error.

As a workaround we are setting the version to =1.19.0 since that is the last known working version.

[jackdoyle]

Sorry about that - please see #190

The path should be resolved now, but it's not in the tagged release. Not sure there's a clean way to shove that into a previous tag (since that kinda goes against the purpose of tags, right?). It should definitely be in the next tag release, though (not sure when that'll be yet, but like I said the file is already edited)

[jptinsman]

should it remain in an open state until it is released in the fix so more people don't try submitting bugs?

[fregante]

You could push a bower-only 1.9.1-0 tag or something like that. Or replace the current git tag

[jackdoyle]

Better now?

[jedierikb]

Thank you, that cleared up the issue for me.
Need to be sure to do a:

rm -rf bower_components
bower cache clean
bower install

per advice here https://github.com/bower/bower/issues/1184#issue-29852859

[jedierikb]

Alas, I've hit a snag with the 1.9.1 update with gsap & bower on osx. Clearing my cache and updating works fine on windows (yea!) However, the same build sequence fails on OSX.

(and reverting my bower.json to "gsap": "=1.9.0"(and only that change) results in a working build on both platforms).

The error is: Error: ENOTDIR: not a directory, stat '/Users/myosxmachine/dev/project/project_dir/bower_components/gsap/src/uncompressed/TweenMax.js/package.json'

Path issue? I wish I was of more help. I fear it is something local to my machine and build environment, but putting it out there in case others bump their head here too. For now, I have reverted to 1.9.0.

[fregante]

To help you we'll need:

• your build tool name and version
• your build config
• as much as possible of your package.json

If you're using a build tool, I highly suggest you remove GSAP from bower and just run

npm install --save gsap

[jedierikb]

Here is a test case which runs successfully on windows10 and not on osX 10.12.3: https://github.com/jedierikb/gsapbowergulp

npm install
bower update
gulp gsaptest

editing bower.json so that "gsap": "^1.19.1" is "gsap": "=1.19.0"

then clearing the bower cache (as described above) and then running the gulp task results in the aforementioned error on osx.

[jedierikb]

Briefly looked into this.
Seems that the addition of "browser": "..." to gsap's package.json now throws the aforementioned error when running the gulp command bundle. I will switch loading this library into my build over to npm instead of bower and see how I fare.

Also, a slight typo was introduced in gsap's package.json on the first word of the "Description" field.

[jedierikb]

& the transfer to npm fixes this issue for me. http://stackoverflow.com/a/23363364/62255 was helpful. I can update my test project if it is helpful for others.

[fregante]

Good to know that switching to npm from bower fixed it. This is always the least-problematic route.

@jackdoyle I'm wondering if package.json should be completely left out from GitHub/bower

[jackdoyle]

@bfred-it Hm, I suspect that if we removed package.json, it'd cause all kinds of problems for various people/systems. Do you think it's causing problems that can't be resolved otherwise?

@jedierikb Thanks for pointing out the typo. You're totally right, of course. I'll get that fixed.

[fregante]

Perhaps the bower package needs its own package.json then, pointing to a file that exists.

[jackdoyle]

Hm, are you aware of a way to have a different package.json file just for bower? I think there's only one "official" package.json (but I could totally be wrong). Maybe I should just change the package.json "main" to point in the "uncompressed" folder again, and change it for the published NPM version (to point at the root).

[fregante]

Right, that's what I meant. NPM gets the root main field (and the browser field) and the rest get the long path.