[@types/react] The remove of onPointerEnterCapture caused unexpected errors.

[Thulof]

Yesterday, @types/react released a new version which removed onPointerEnterCapture. #68984

However, this change has resulted in unexpected errors.

A reproduction path:

Consider a project A that uses an older version of @types/react and exports a component wrapped with forwardRef, where the component's props type is a complex type that with React.HTMLAttributes.

When this component is used in project B, which utilizes a newer version of @types/react, there will be an error indicating that the onPointerEnter property is missing.

error TS2739: Type '{ children: string; }' is missing the following properties from type 'Pick<IDemoProps, "slot" | "style" | "title" | "type" | "key" | "defaultChecked" | "defaultValue" | "suppressContentEditableWarning" | "suppressHydrationWarning" | ... 249 more ... | "ellipsis">': onPointerEnterCapture, onPointerLeaveCapture

Reason:

The forwardRef function performs an Omit<props, 'ref'> operation on the props.

In the final type declaration file generated by project A, the Omit sometimes gets transformed into Pick. See #61757

If project A is using an old version of @types/react, this eventually turns into Pick<React.HTMLAttributes, ... | 'onPointerEnterCapture' | ...>.

Since project B is using a newer version of @types/react, where React.HTMLAttributes no longer includes onPointerEnterCapture, the onPointerEnterCapture is considered of an unknown type in the final prop types.

At this point, it becomes a required property, thus the usage of the component in project B demands that onPointerCapture must be provided.

In a project, numerous npm packages are used. If an npm package depends on an older version of @types/react, and the project that uses this package requires a newer version (for instance, the version specified for @types/react in the package.json devDependencies field is "17.x" or "latest"), then the issue described above will occur when developers simply run pnpm i.

[typescript-bot]

Thanks for the discussion about "react", some useful links for everyone:

• npm
• DT
• Related discussions

Pinging the DT module owners: @johnnyreilly, @bbenezech, @pzavolinsky, @ericanderson, @DovydasNavickas, @theruther4d, @guilhermehubner, @ferdaber, @jrakotoharisoa, @pascaloliv, @Hotell, @franklixuefei, @Jessidhia, @saranshkataria, @lukyth, @eps1lon, @zieka, @dancerphil, @dimitropoulos, @disjukr, @vhfmag, @hellatan, @priyanshurav, @Semigradsky, @mattpocock.

[Thulof]

I have created a revert PR to roll back @types/react to its previous state, in order to avoid having everyone encounter this error after updating their dependencies. #69005

[eps1lon]

Multiple versions of the React types in a single application are not supported just like mutliple versions of React in an app are not supported.

Could you provide a full, minimal example that shows the issue?

[matej-marcisovsky]

What is the point of using DefinitelyTyped if the types it provides are wrong? Reverting this would not help anything in the long term. I believe that this is the only way that maintainers of other packages would fix this in their versions. Let them know by reporting an issue or creating a pull request. Or you can just freeze @types/react in your projects if your project is in maintenance mode, not worth the trouble, etc.

We could mark these two events as deprecated with TSDoc, but this is not the case. They are not deprecated. They never existed.

Reverting this fix would not affect me personally (I know now that this bug exists), and the final decision is not on me. I sympathize with your issues, but there are other developers that have no idea about this bug and are relying on TypeScript types, sometimes more blindly than they should.

[Thulof]

I agree with your perspective; we should adhere to correctness instead of compromising due to historical legacy issues or development costs. I am very thankful to everyone, as this has allowed me to understand the differences between maintaining an open-source project and a corporate project.

[eps1lon]

Either you manually picked onPointerCapture and relied on a bug, or this was TypeScript wrongfully inlining a type. We reported this before and got no buy in. There is now a dedicated issue you can subscribe to and upvote to help prioritization: microsoft/TypeScript#57779

[eps1lon]

@Thulof It would help a lot if you can comment in microsoft/TypeScript#57779 what code you authored and what TypeScript inlined to add another case where inlining is incorrect.

[Thulof]

@eps1lon OK, I will tidy up the previous minimal reproduction project, ensuring that only the essential parts remain, and then I will comment it in microsoft/TypeScript#57779.

[RJM1996]

I encountered this issue a few days ago too! It turned out to be caused by an upgrade of the @types/react version, which cost me half a day!

[martymh]

👍 Seeing exactly the same type of error with a recent update to @types/react 17.0.78.

error TS2739: Type '{ ... }' is missing the following properties from type 'Pick<...>': onPointerEnterCapture, onPointerLeaveCapture

[eps1lon]

I'll revert this for the older type versions since those will most likely not be fixed since it would require re-publish of the affected libraries with the latest 17.x types. The change stays for React 18 types though.

Backports should be reserved for critical bug fixes and given how long we had this bug in, it doesn't seem critical.

If you're affected, please follow microsoft/TypeScript#57779 as well.

[peatiscoding]

As for work around we are using this type augmentation.

// src/global.d.ts
import 'react'

declare module 'react' {
  interface HTMLAttributes<T> {
    onPointerEnterCapture?: (e: React.PointerEvent<T>) => void
    onPointerLeaveCapture?: (e: React.PointerEvent<T>) => void
  }
  interface RefAttributes<T> {
    onPointerEnterCapture?: (e: React.PointerEvent<T>) => void
    onPointerLeaveCapture?: (e: React.PointerEvent<T>) => void
  }
}

[joshualip-plaudit]

So... Is there any update on workarounds besides using type augmentation to put the removed properties back? It's extremely annoying, and the task we're told to follow doesn't exactly help.