pmndrs / pmndrs/react-spring

Remove `any` from public types

Open
#2,541 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area: typescript kind: request release: major
Dominant language
TypeScript
Stars
29.1k
Forks
1.2k
PR merge metrics
No merged PRs in 30d

Description

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:

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in packages/core/src/types/props.ts, then trace the public types used by hook return values, lifecycle handlers, spring values, and the render prop. Use the related issues #2183, #2006, #1114, and #1483 to understand the affected surfaces; done means accidental any no longer leaks into consumer-facing types while deliberate internal variance remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.