Upgrade our Repo to React 17, tests, VR, examples, etc.

[ling1726]

[some partners are rolling out R17 now, others are planning]

[ling1726]

Enzyme does not officially support React 17 enzymejs/enzyme#2430

An unofficial adapter exists, but no guarantee all tests work https://www.npmjs.com/package/@wojtekmaj/enzyme-adapter-react-17

[ecraig12345]

Related: #15732, #16886

[ecraig12345]

After #22265, all the tests included in yarn test appear to be working with React 17 and @wojtekmaj/enzyme-adapter-react-17.

[ecraig12345]

Trying out React 17 again (draft): #22326

Probably everything works except a weird issue with unmounting northstar Popup in tests (not sure if it's a real issue too): #22326 (review)

[ecraig12345]

As of writing, all the tests work against React 17 (it's possible new breaks could be introduced), but the upgrade attempt (#22326) got blocked when I tried to update the @types/react dev dep to 17.

The latest @types/react 17 version as of writing (17.0.44) includes a reference to Iterable, which is from lib.es2015 and therefore won't compile in v8 packages that only reference lib.es5.

type ReactFragment = {} | Iterable<ReactNode>;

Iterable usage was introduced in 17.0.32, so you could probably work around the issue by setting the repo's @types/react dev dep to 17.0.31. (Anyone looking back at this issue later can also check latest 17 to see if the issue has been resolved.)

Some clarifying notes:

• Yes this issue is technically limited to v8 packages since they're the only ones that still use lib.es5, but it affects the whole repo unless you want to start introducing different @types/react dev deps per package (not recommended)
• This should not* affect any package's public API: for consumers, @types/react is already a peer with range >=16.8.0 <18. The version being discussed here is the dev dep within the fluent repo.

* Qualifiers for "should not": The repo's internal @types/react version hopefully shouldn't affect consumers, but I can see a couple ways this could break (so from this perspective, staying on 16 dev dep might be safer).

• Type alias expansion in generated .d.ts might expose internals of react types in fluent's .d.ts--but I haven't done any testing to see whether this happens in practice. Also this issue was only observed with v9 that I know of, in which case the lib es5 issue doesn't apply. (And pinning to 17.0.31 would eliminate the possibility.)
• With the complexity of the v9 compose types, it's possible that once the repo upgrades to React 17 types, it would be easier to accidentally change the compose types in a way that's not compatible with React 16 types (like referencing newly-added React type names, or types whose implementation has changed). One way to prevent this would be adding a test similar to typescript minbar but running against different @types/react major versions.

[micahgodbolt]

Sean mentioned that event delegation in layers in React 17 can cause some issues. Make sure to take a look at that area.