Jump to content
Search Community

npm deployment with public repo

leastbad test
Moderator Tag

Recommended Posts

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.

Link to comment
Share on other sites

25 minutes ago, pjforde1978 said:

Once you catch all of the documentation issues (Draggable seems to have literally improved overnight!)

I wasn't quite sure what you meant - are you saying that there are a bunch of documentation issues? If so, would you mind giving us a little more detail? (Parts of the docs are a work-in-progress, admittedly). And when you said Draggable seems to have improved overnight, what did you mean? The GSAP 3 version or the docs or something else? 

 

27 minutes ago, pjforde1978 said:

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.

Very kind of you. I often tell people we've got the best users around. I really believe that. 

 

28 minutes ago, pjforde1978 said:

This way developers could comfortably set inertia:true regardless of whether it's available or not.

Yeah, it should actually work exactly that way now - if you set inertia:true but IntertiaPlugin isn't present/registered, it just ignores the inertia stuff (it doesn't break your whole Draggable thing). Is that pretty much what you're looking for? 

 

That's not a bad idea about the localhost:3000 thing. I'll ponder that. ?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

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