Remove `any` from public types

Author: joshuaellisCreated Jun 11, 2026Updated Jun 12, 2026
Labelskind: requestarea: typescriptrelease: major

A clear and concise description of what the feature is

Tighten the consumer-facing TypeScript surface — replace accidental any on public types (hook return values, handler arguments like onChange, the values read off a spring) with accurate types, so the API describes what it actually accepts and returns. Scope is any that leaks into user code, not the deliberate variance any the engine relies on internally.

Two examples in the code today, both in packages/core/src/types/props.ts:

typescript
// Every lifecycle callback is `any` — handler arguments are unchecked
export interface ReservedEventProps {
  onStart?: any
  onChange?: any
  onRest?: any
  onDestroyed?: any
  // …
}

// Reserved animation/transition props are `any`, including the render prop
export interface ReservedProps extends ReservedEventProps {
  to?: any
  from?: any
  config?: any
  enter?: any
  leave?: any
  children?: any
  // …
}

Why should this feature be included?

Accidental any on public surfaces silently switches off type-checking for consumers: no autocomplete, no error when the shape is wrong, no editor guidance. It's a recurring source of user-reported bugs:

  • #2183 — onChange receives the wrong (any) result type.
  • #2006 — <Spring> render prop is inferred as any (breaks under noImplicitAny).
  • #1114 — onDestroyed type definition is wrong.
  • #1483 — useTransition inference fails when styles are set via functions.

Tightening these makes the real public type surface explicit and gives consumers accurate IntelliSense and call-site errors.