Currently react and react-is are built using a shared/ package. That means that react-is (just like react-dom) has to have the same version number as react to avoid potential issues due to different code from shared/.

However, right now a lot of libraries are wrongly declaring react-is as a direct dependency¹ while declaring react as a peer. Technically correct would be declaring react-is as a peer as well leading to more burden for app developers. This is slightly different to having react as a peer dependency because every app developer also needs react as a dependency. The same doesn't always hold true for react-is.

Since react-is has no dependencies it would be more ergonomically for libraries if react-is would be available from react/is since they already have react as a peer dependency. There are two possibilities for this:

1. Move react-is to react/is
2. Make react-is a dependency of react and re-export it from react/is

I guess marking react-is as a peer would be the approach that would be more consistent. It's really just annoying for libraries but if that's what you would recommend then I'm fine with it as well.

As far as I can tell this is really just a technicality right now i.e. I haven't seen any actual issues. I just stumbled over it while working on React 17 compat. So far it looks like we're in a position to declare 16.8 and 17 as the range for react in our peerDependencies which leaves us with a slightly awkward "react-is": "^16.8.0 || ^17.0.0" in the dependencies (I might be trying too hard to avoid additional peer deps).

¹ Popular examples include prop-types, react-redux, react-router, @material-ui/core, next