[DUPLICATE] Types: Resolve conflicts with DefinitelyTyped

[sirreal]

See #21767 (this is a duplicate)

Summary

@wordpress/* have begun to emit TypeScript type declarations and package them with the published packages. Shortly after publishing it was discovered the @wordpress/element conflicted with the DefinitelyTyped 3rd party type declarations (DT) of several packages and a patch release was published removing the published types from @wordpress/element, @wordpress/primitives, and @wordpress/icons (#21613).

This issue is for the purpose of laying out the problem and discussing paths forward.

The problem

One major purpose of @wordpress/element is an abstraction over React. In many ways, it is a very thin layer that re-exports React functionality.

Third party types on DT and expose all of the React types. The implementation in the @wordpress/element package is selective about what it exposes from React.

This means that the DT types for @wordpress/element exposes all of the React types, and other @wordpress/* DT types make use of react via @wordpress/element. For example ComponentType in @wordpress/blocks is React's ComponentType.

When the 1st party @wordpress/element types were published, they superseded the DT types causing a cascade of issues for other DT types depending on @wordpress/element for React types.

Considerations

In an ideal future, all packages provide 1st party type declarations which are verified by the TypeScript type system. The need for 3rd party types will go away and the types can be deprecated. There is a significant amount of work to do before we can realize this future.

In the interim, DT types provide value for packages that don't yet publish their own declarations.

Packages other than the DT types may rely on the @wordpress/element-provided React types.

Possible solutions

Please edit to add additional solutions. It's worth considering all paths forward.

Use React types directly from react

Rather than expose React types from @wordpress/element, @wordpress/element and other packages would reference React types directly.

Pros: Simplicity, clear path forward, less to maintain.
Cons: Exposes React directly to consumers, breaking the facade.

Ignore conflicts with DT

We could republish the @wordpress/element package with types as it is now. This is known to break some DT types and will affect consumers relying on those types.

Pros: Requires no effort.
Cons: Anyone relying on DT types for certain packages in negatively impacted.

We don't strictly have any obligation to maintain compatibility with DT types. I would discourage this course of action.

Expose React types from @wordpress/element

Just like @wordpress/element eposes a lot of functionality from React, types could also be exposed. In practice, this has proved to be difficult.

Pros: Maintain the facade in front of React.
Cons: A lot of work.

While TypeScript has clear ways of importing and exporting types, I was unable to re-export React types from @wordpress/element via JSDoc. At the very least, this would mean taking on a significant maintenance burden.

[annezazu]

Closing this as it seems to be a duplicate of this issue: #21767 If that's wrong, definitely re-open :)

[sirreal]

This was a duplicate created during degraded GitHub service. Thanks for cleaning up 👍