Bad EaseString type

[braebo]

The EaseString type has string in the union:

GSAP/types/gsap-core.d.ts

Line 182 in 6032c54

| "sine" | "sine.in" | "sine.out" | "sine.inOut" | string;

This widens the type and hides the string literals from intellisense:

This allows any string and the autocomplete is just random globals. It should probably be removed altogether and users should use string literals and the const modifier for typesafety... but a compromise would be changing the type to this:

    //...
    | "sine" | "sine.in" | "sine.out" | "sine.inOut" | ({} & string);

By using ({} & string), the type will still allow arbitrary strings, but now the autocomplete works:

I was going to submit a PR, but it doesn't look like you guys accept those 😅

[jackdoyle]

Interesting, thanks for the suggestion @fractalhq. I'm not much of a TypeScript guy myself. We definitely need to accept arbitrary strings because that's how CustomEase works (you can assign a name to any ease, or you can even pass 4 comma-delimited bezier numbers).

So to confirm, you're saying that ... | ({} & string) will indeed allow arbitrary strings, so we get the best of both worlds and there won't be backward compatibility issues (like if someone isn't running the latest version of TypeScript)?

[braebo]

Correct! I'm not positive about backwards compatibility though -- googling a bit lead me to this post https://stackoverflow.com/a/61048124

The last comment claims the fix doesn't work for 3.8, while it does in ^4.x. I'm not sure if that means it simply doesn't fix autocomplete, or if it explicitly introduces a new compiler error. I'd assume the former, but testing it out might be warranted if you want to support v3 (although we're on 5.2 these days).

[jackdoyle]

Got it, thanks. Seems to still work on 3.x from what I can tell. I'll add this to the next release.

[raulfdm]

For reference: https://github.com/sindresorhus/type-fest/blob/main/source/literal-union.d.ts