Describe the bug
@wix/motion exports a cssEasings object (a map of ~30 named easings to their cubic-bezier(…) values), but it is not documented, its keys are not exposed as a TypeScript type, and preset rule types use easing?: string rather than referencing a named-easing union. Consumers can only discover it by guessing the import exists.
// This works at runtime but is undocumented and untyped:
import { cssEasings } from '@wix/motion';
console.log(cssEasings);
// { linear: '...', ease: '...', easeInQuad: '...', easeOutCubic: '...', … }
// No exported type for the key set — have to derive it ourselves:
type CssEasingName = keyof typeof cssEasings;
// Preset easing fields accept these names but are typed as `string`:
const timing: EffectTiming = { easing: 'easeInQuad' }; // no autocomplete, no validation
To Reproduce
- Install
@wix/motion@2.1.3
- Search the published README / API docs for "cssEasings" or "named easings" — no results
- Open
node_modules/@wix/motion type declarations — no CssEasingName or equivalent union type is exported
- Try typing
easing: '...' in a preset config — get string, no autocomplete for valid easing names
- Discover
cssEasings only by browsing the package's runtime exports or source
Expected behavior
cssEasings is documented as a public export with its keys listed
- A union type (e.g.
CssEasingName) is exported so consumers can type easing parameters against the known set
- Preset rule types for
easing fields reference that union (or at minimum document that named easing strings from cssEasings are accepted)
Screenshots
N/A — this is a docs/types gap, not a visual bug.
Desktop
- OS: macOS 15.4
@wix/motion: 2.1.3
@wix/motion-presets: 1.0.0
- TypeScript: 5.x
Additional context
Any tool that builds an easing picker (dropdown, autocomplete, curve preview) needs the canonical set of named easings. Currently this requires guessing the undocumented export exists, then deriving the key set at runtime. There is no compile-time safety when passing easing names to preset configs. A workaround:
import { cssEasings } from '@wix/motion';
const NAMED_EASINGS = Object.keys(cssEasings).map(name => ({
value: name,
label: name.replace(/([a-z])([A-Z])/g, '$1 $2'),
}));
Describe the bug
@wix/motionexports acssEasingsobject (a map of ~30 named easings to theircubic-bezier(…)values), but it is not documented, its keys are not exposed as a TypeScript type, and preset rule types useeasing?: stringrather than referencing a named-easing union. Consumers can only discover it by guessing the import exists.To Reproduce
@wix/motion@2.1.3node_modules/@wix/motiontype declarations — noCssEasingNameor equivalent union type is exportedeasing: '...'in a preset config — getstring, no autocomplete for valid easing namescssEasingsonly by browsing the package's runtime exports or sourceExpected behavior
cssEasingsis documented as a public export with its keys listedCssEasingName) is exported so consumers can type easing parameters against the known seteasingfields reference that union (or at minimum document that named easing strings fromcssEasingsare accepted)Screenshots
N/A — this is a docs/types gap, not a visual bug.
Desktop
@wix/motion: 2.1.3@wix/motion-presets: 1.0.0Additional context
Any tool that builds an easing picker (dropdown, autocomplete, curve preview) needs the canonical set of named easings. Currently this requires guessing the undocumented export exists, then deriving the key set at runtime. There is no compile-time safety when passing easing names to preset configs. A workaround: