Inspecting the JavaScript source for this package found some properties that are not in the .d.ts files.
The check for missing properties isn't always right, so take this list as advice, not a requirement.

babel-plugin-react-html-attrs (unpkg)

was missing the following properties:

1. The declaration doesn't match the JavaScript module 'babel-plugin-react-html-attrs'. Reason:
   The JavaScript module can be called or constructed, but the declaration module cannot.

gatsbyjs__reach-router (unpkg)

was missing the following properties:

1. BaseContext
2. LocationContext
3. insertParams
4. match
5. navigate

reach__router (unpkg)

was missing the following properties:

1. matchPath
2. matchPath

react-bootstrap-typeahead (unpkg)

was missing the following properties:

1. useHint
2. Input
3. asyncContainer
4. useAsync
5. withAsync

react-map-gl (unpkg)

was missing the following properties:

1. AttributionControl
2. setRTLTextPlugin
3. MapContext

react-onclickoutside (unpkg)

was missing the following properties:

1. IGNORE_CLASS_NAME
2. IGNORE_CLASS_NAME

react (unpkg)

was missing the following properties:

1. unstable_act

tuya-panel-kit (unpkg)

was missing the following properties:

1. Drawer
2. Wave
3. Diffusion
4. OfflineView
5. FullView

wordpress__components (unpkg)

was missing the following properties:

1. CustomGradientPicker
2. DuotonePicker
3. DuotoneSwatch
4. GradientPicker
5. GuidePage

wordpress__rich-text (unpkg)

was missing the following properties:

1. store

Generated by 🚫 dangerJS against 95c7b2e

I kept MutableRefObject around so that anyone using RefObject in their application code would not have the type change from under them and represented RefObject with MutableRefObject. It seemed like a cleaner deprecation path.

I also think if we are making breaking changes for React 19, we should not allow the zero argument version of useRef() since there are no documented uses in react. The behavior of useRef<T>() implying { current: T | undefined } is really confusing to most people when we inherit null in the other cases. I think either useRef<T>() needs to be { current: T | undefined | null } or needs to not exist. Both cover issue 2 in the referenced tweet.

I also think if we are making breaking changes for React 19, we should not allow the zero argument version of useRef() since there are no documented uses in react.

We track this separately in #64920. This PR is not stacking all React 19 changes.

The behavior of useRef() implying { current: T | undefined } is really confusing to most people when we inherit null in the other cases.

Which other cases?

I think either useRef() needs to be { current: T | undefined | null } or needs to not exist.

{ current: T | undefined | null } will not be assignable to React managed refs since object properties are covariant in TypeScript. We cannot change that at the types declaration level. We need contravariant object properties for that: microsoft/TypeScript#21759 (comment)

#64920 will propose its non-existent i.e. only useRef<T>(undefined): { current: T < undefined } will exist (i.e. convenience overload for undefined just like null.

Hi @eps1lon. What would be the recommendation for the refs that are handled by React, i.e.:

const divRef = React.useRef<HTMLDivElement>(null)

// ...

<div ref={divRef} />

If I understand correctly, divRef will be mutable in React 19. Should we keep it as such even though it's not supposed to be mutated? Is this restriction outside of @types/react's scope?

I don't have an opinion on it, just wondering what is the recommended usage.

If I understand correctly, divRef will be mutable in React 19. Should we keep it as such even though it's not supposed to be mutated?

There was never such a restriction that you shouldn't mutate it. React will not read this value so you can write whatever you want into that value. You just need to be aware that React may overwrite what you wrote into the ref. But that would equally apply to all instances where you pass a ref to multiple places that will write to it.

Thanks for the reply!

There was never such a restriction that you shouldn't mutate it.

This confuses me a bit, wasn't the readonly in

interface RefObject<T> {
    readonly current: T | null;
}

A restriction about not mutating it?

A restriction about not mutating it?

At the type level, yes. But types are in service to how we want React code to be authored. And there this restriction never existed.

Thanks for the clarification