[react-is] The major versions of react and react-is must be peerDependencies related.

[ashidaharo]

(This is not directly related to React 18, but it is a discussion about breaking changes, so I'm proposing it as a topic for the next major release.)
Clearly react-is works on the assumption that it will be used with a matching version of react.
Therefore, react should be listed as a peerDependencies of react-is.

I brought this up from a discussion involving a package that depends on react-is downstream.

[ashidaharo]

...When I think about it again after creating this issue, it seems to be a problem with react 17.
React 17 claims to "React 17 enables gradual React upgrades." However, react-is, which implicitly depends on react, is clearly not well adapted to such behavior.

[eps1lon]

See #20099 for prior discussions.

[ashidaharo]

@eps1lon
Thank you for letting me know. I had missed it because I only saw the title and the suggestions seemed to have different content.
Here are some thoughts I had after reading the discussion.

#20063 (comment)

(The problem I was imagining is if it were using something like isValidElementType and the 17 element types eventually changed over time, e.g., by addition of new types, such that the shallow renderer would get assertions that would be inaccurate from the POV of React 16.)

This was the original point I brought the discussion from downstream to here.
That module uses exactly "shared/isValidElementType.js", and obviously that package can't handle both ^16 and ^17 support for react. (This function has obviously undergone a breaking change between v16 and v17.)

#20099 (comment)

We're probably going to recommend not using that package altogether. It doesn't work great if you consider different environments (e.g. Server Components). Given that it's not recommended, we won't make it a part of the core package.

And this is... uh... because I'm reading the discussion using a translation? I'm having a hard time interpreting this.
Is he saying that he doesn't recommend using react-is, or is he saying that he doesn't recommend packages that directly depend on react-is?

[bvaughn]

Is he saying that he doesn't recommend using react-is

Yes. Dan was saying this.

[ashidaharo]

...React-is currently plays the role of checking for react elements in the ecosystem (and I think it's often used as a partial reference to the react internal spec, but that's another story), so what packages should be used instead?
For example, React developers recommend using a type system such as typescript or flow because such problems occur because of the untyped world? ...but the project itself doesn't directly disclose the type definitions...