chore(deps): Update components to use new JSX transform

[mfrances17]

What: Closes #11553

This addresses the new JSX transform changes that were first introduced in React 17, in short, we no longer require import react statements for files that only needed it for JSX. Files that require a react import for non-globals e.g. for hooks like useEffect will still require the import, but they must be named imports instead of the generic import React from 'react', import * as React from 'react', etc.

I've updated the associated eslint rule to throw an error now that the sweep is complete and everything is building cleanly.

Including @jonkoops on this as well.

[patternfly-build]

Preview: https://patternfly-react-pr-11582.surge.sh

A11y report: https://patternfly-react-pr-11582-a11y.surge.sh

[jonkoops]

Because the tests are being excluded in the TSConfig the new "jsx": "react-jsx" option is not being applied to them. This means that when you open a test file that has JSX in it (e.g. Chart.test.tsx) you'll get an error message.

This will have to be fixed so that either the tests are no longer excluded from tsconfig.base.json or another TSConfig should be added for the tests that extends this base and then includes the tests again. Additionally, this means the tests are currently not being type-checked, which can lead to accidental regressions.

Note that the same currently applies to the example projects, which seem to have actual type errors. Perhaps this is best handled separately in a different PR so this one can be rebased on top.

[mfrances17]

This means that when you open a test file that has JSX in it (e.g. Chart.test.tsx) you'll get an error message.

The troublesome part of this is that I don't see any these errors, either in the build or in the IDE, although I know you are experiencing them. It's making it difficult to debug and find a solution when I'm not able to reproduce on my end. I'll keep at it, perhaps we need a tests-specific tsconfig that has the same JSX options as the base tsconfig.

[jonkoops]

I took a look at all the files, and it all looks good to me. As far as I am concerned this PR can be merged, and I think we should do it sooner rather than later to avoid conflicts.

[wise-king-sullyman]

As discussed on Slack I don't love that some of the markdown examples now aren't including the react related imports directly in the examples themselves.

Other than that LGTM, and as discussed I'm fine with that fix being in a followup PR so that this can get merged sooner rather than later.

[jonkoops]

As discussed on Slack I don't love that some of the markdown examples now aren't including the react related imports directly in the examples themselves.

React is going to a place where the compiler is responsible for making the right imports, so users should really be instructed to no longer include it. I'd argue it is good to educate them now, if you bootstrap a new React project this behavior is the default.

[wise-king-sullyman]

React is going to a place where the compiler is responsible for making the right imports, so users should really be instructed to no longer include it. I'd argue it is good to educate them now, if you bootstrap a new React project this behavior is the default.

Hook imports and such will no longer be needed?

[jonkoops]

Hook imports and such will no longer be needed?

Oh sorry, I thought you were referring to the import React from 'react' statement. No, named imports will have to still be included. In that case, agreed, this is unfortunate, perhaps it will be mitigated with the new documentation framework?

[tlabaj]

LGTM

[dlabaj]

LGTM

[thatblindgeye]

As part of the rebase, we shoulld revert the default value of the forwardScrollAriaLabel prop in NavList and instead open an issue to fix that in the next breaking change. Ohterwise components and demos looked good.