leastbad

Thanks, Zach! FWIW, I only got to the v2 page from the Plugins section on the main Products page. Also, when you're on the v2 PixiPlugin page, clicking to go to the v3 version takes you to the homepage.

I am excited to use GSAP to drive Pixi 5, but I noticed the PixiPlugin seems to be a GSAP 2.x plugin. Is PixiPlugin still relevant in the GSAP 3.x dimension? I'd appreciate any tips/pointers to excellent starter tutorials (blog or video) showing how to use GSAP 3 and Pixi 5 together.

Hey @OSUblake, thanks for taking a look at this... although I fear you might be skimming quickly and jumping to incorrect conclusions. I'm making examples, but they are for our project, not GreenSock. I linked to it earlier; StimulusReflex is a Rails library. Rails uses npm/webpack and in our community, we predominantly use the modern import syntax. Our client library is also tightly integrated with Stimulus and it's import all the way. A large and increasing number of sites on the web publish the code for their public marketing sites on GitHub. That means a company who is savvy enough to use GreenSock but transparent enough to publish their own code now finds themselves in the pickle I'm in. Given that you folks have done such an amazing job of making GreenSock work across so many varied configurations over multiple generations of tools, it's clear that you also have a vested interest in future-forward scenarios, too... v3 is the ultimate proof of that! I'm biased, but I honestly think it might be rash to write this scenario off as essentially off-topic. I'm an experienced dev willing to work with you to discover a solution to a problem case that emerges from your product's licensing model. I actually think your model is amazing, which is why I'm so happy I've purchased a shockingly green membership and we're talking about trying your model on our project. But at the end of the day, most libraries you include in your package.json have a dual-licensing scheme attached. I'm not bummed that there is a problem, but it is important to find a solution. What you describe as confusing is also a viable solution to the problem. The algebra that needs to be performed is "how confusing is it, and is this amount of confusing less than the positive that comes from solving the problem?" From my perspective, the answer is a clear yes because webpack is definitely where things are trending. Meanwhile, folks downloading the public version of GreenSock aren't expecting Inertia to be there and if they include it anyhow, you have an opportunity to encourage them to join.

Yesterday, the Draggable page that I linked to still contained multiple references to throwProps and didn't actually include a mention of the new inertia property on the Draggable class. I had to look at the source to verify the new key was in fact inertia. Today, there's lots of info about the InertiaPlugin on the page. That's awesome. I also briefly was forced to manually set the height of the DOM element containing the documentation copy to a large value because it was being clipped on every page; happily, that bug seems to have been resolved as well. I will definitely start to make a list of versioning issues as I come across them. Seems like you're on it, though. Sorry for the length of my first note; I suspect it made it difficult to parse and answer in turn. Let me try terse: 1. I want to showcase a demo on our site that uses paid GSAP features. Your npm instructions work great for local development and secure deployment; our demo site itself is available on GitHub and serves as a primary learning on-ramp for our users. Is there a good strategy (pre-commit git hooks?) for swapping out the gsap dependency in package.json from "gsap": "./gsap-bonus.tgz" to a standard npm dependency without maintaining two separate codebases (a non-starter for many reasons)? 2. If I have... import { InertiaPlugin } from 'gsap/InertiaPlugin' gsap.registerPlugin(Draggable, InertiaPlugin) ... in my source but our user is running the free version of GSAP, webpack is going to get very upset at them. However! If you created stub versions of the membership-level modules such as InertiaPlugin that literally only raise console warnings alerting you to your situation, then this code will be safe even for people still evaluating the product. I'm also open to other great ideas - I'm not a webpack expert. Perhaps there's a way to tell webpack to "import if it's available" that I don't know about?

Partitioning the Http Cache ¯\_(ツ)_/¯

I just wanted to give everyone some advance notice that the browser makers are doing away with the notion of a shared browser cache over the next year or so. In practical terms, this means that we can no longer rely on browsers to have GSAP cached even though it's hosted on a CDN. This is a major departure from the past, and unfortunately might come as a bit of a downer if you're trying to minimise your JS payload footprint. https://www.jefftk.com/p/shared-cache-is-going-away

Hi gang! I'm new to the party but just finished my first GreenSock implementation. Congrats on v3! Seems like I showed up at the perfect time. Once you catch all of the documentation issues (Draggable seems to have literally improved overnight!) this library will truly be my new favourite thing. For example, here is my implementation of a fancy knob that will scrub at variable speed depending on how far you turn it to the left or right. It will scrub even when you're not dragging the knob. Experience gives me the wisdom to recognise that this implementation would not be terse or possible without such a well-thought out API surface. Kudos! knobber (element) { const timeline = gsap.timeline({ repeat: -1, onRepeat: () => { const r = ~~draggable.rotation timeline.repeatDelay(gsap.utils.mapRange(0, 180, 1.0, 0.1, Math.abs(r))) // this.direction(r > 0) } }) timeline.pause() timeline.to({}, { duration: 0.1 }) const draggable = Draggable.create(element, { type: 'rotation', inertia: true, onDragStart: () => timeline.play(), onDragEnd: () => timeline.pause(), snap: () => { return 0 } })[0].applyBounds({ minRotation: -180, maxRotation: 180 }) } Anyhow, the issue I'm now faced with is that this implementation is extracted from a demo I've prepared for our project, StimulusReflex. As you're well aware, it will work without Inertia, but it simply won't be as sexy. I'm actually perfectly happy to recommend that people purchase a GSAP membership, but I don't want to violate your TOC (or trust) by putting the gsap-bonus.tgz on our public repo. Right now I have it set up with yarn/webpack pulling in the local archive as your npm instructions describe. (You might want to tell people to purge their caches to get rid of old versions, btw!) This works great for my workstation and for deploying to Heroku, but how do you suggest I handle the package management issue? If I was to push the repo as-is to production, anyone checking out the code to experiment with locally is going to get slapped by yarn/npm because that file doesn't exist. I actually do have a suggestion for how you could approach this: add localhost:3000 to your CDN whitelist so that people can experiment with the paid tools on their own machine, but in a way where they can't deploy it. This has actually worked fairly well for FontAwesome, who actually took it a step further to allow paid users to whitelist their project domains through a web interface. The other related question I have is about what I'll call progressive enhancement: is there a way to detect whether you're running the paid version and if Inertia was available from inside your webpack context? Specifically, I want to import Inertia if it's available and skip it if it's not. This would include passing InertiaPlugin to gsap.registerPlugin and even dynamically passing true/false to the inertia var when creating a Draggable instance. If there's a good strategy for this which won't make webpack angry if the file doesn't exist, I'd love to hear about it. Again, I propose a solution: include an InertiaPlugin.js in the OSS version on GitHub that has function signature placeholders - like a Java interface - but only actually spits out console warnings if it's not present. This way developers could comfortably set inertia:true regardless of whether it's available or not.