feature: Move react-is to react/is

[eps1lon]

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

[bvaughn]

🤡

react/packages/react-test-renderer/package.json

Lines 21 to 23 in 4e5d7fa

	"dependencies": {
	"object-assign": "^4.1.1",
	"react-is": "^17.0.1",

[eps1lon]

Now that I think about it I think re-exporting react-is from react is only technically correct if pinned to patch versions and if the version always matches. If pinned to major (caret range) the following scenario creates a mismatch of react-is and react:

1. React 16.12 is released
2. Install react: yarn add react-test-renderer@16.12.0 (installs react-is@16.12.0)
3. React 16.13 is released
4. Upgrade react: yarn add react@16.13.0 (keeps react-is@16.12.0 due to lockfiles)

[billyjanitsch]

@eps1lon see #20063 (comment).

[gaearon]

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.

[Andarist]

We're probably going to recommend not using that package altogether

If react-is is not recommended then what is the recommended approach when having to test for element types etc?