[core] Bump React to 19 #42824

aarongarciah · 2024-07-02T15:55:49Z

This PR serves as a sandbox to check how many issues we have left to solve to support React 19.

DiegoAndai · 2024-07-09T21:02:53Z

@aarongarciah, we're working on the Emotion type fixes alongside the Emotion maintainers: emotion-js/emotion#3206

The next issue I'm facing is with the following packages:

styled-components used in the @mui/styled-engine-sc package, used for integrating with styled-components
next@13 used in the @mui/material-nextjs package.

Neither of these are up to date, and I don't think it's worth it for us to to try and update them like we did with Emotion:

The styled-components package is outdated (@types/react: 17) and not very active, there's a two year old React 18 issue with no response 😅: React 18 compatibility? styled-components/styled-components#3738
Version 13 of next is their previous major and I don't think updating would be a priority. Also, @mui/material-nextjs already supports next@14

So I think we should deprecate @mui/styled-engine-sc as well as the next@13 version of @mui/material-nextjs (keeping next@14 support). What do you think about this approach? The only problem I'm having is that I don't know how to freeze the React 18 for these deprecated packages as we cannot remove React 19 from the resolutions.

aarongarciah · 2024-07-10T12:47:18Z

So I think we should deprecate @mui/styled-engine-sc as well as the next@13 version of @mui/material-nextjs (keeping next@14 support).

@DiegoAndai I think this makes sense.

The only problem I'm having is that I don't know how to freeze the React 18 for these deprecated packages as we cannot remove React 19 from the resolutions.

Can you expand a bit? I assume you're talking about the top level package.json resolutions. Can we add a resolutions key to @mui/styled-engine-sc to force React 18 types? Not sure how we'd solve the problem in @mui/material-nextjs only for nextjs@13.

mui-bot · 2024-07-10T20:57:46Z

Netlify deploy preview

@material-ui/core: parsed: +Infinity% , gzip: +Infinity%
@mui/joy: parsed: +Infinity% , gzip: +Infinity%
@material-ui/lab: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Autocomplete: parsed: +Infinity% , gzip: +Infinity%
Autocomplete: parsed: +Infinity% , gzip: +Infinity%
TextField: parsed: +Infinity% , gzip: +Infinity%
@material-ui/unstyled: parsed: +Infinity% , gzip: +Infinity%
SpeedDialAction: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Select: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Menu: parsed: +Infinity% , gzip: +Infinity%
Tooltip: parsed: +Infinity% , gzip: +Infinity%
SwipeableDrawer: parsed: +Infinity% , gzip: +Infinity%
TabList: parsed: +Infinity% , gzip: +Infinity%
SpeedDial: parsed: +Infinity% , gzip: +Infinity%
Pagination: parsed: +Infinity% , gzip: +Infinity%
Alert: parsed: +Infinity% , gzip: +Infinity%
LoadingButton: parsed: +Infinity% , gzip: +Infinity%
Popover: parsed: +Infinity% , gzip: +Infinity%
Drawer: parsed: +Infinity% , gzip: +Infinity%
PaginationItem: parsed: +Infinity% , gzip: +Infinity%
and 271 more changes

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 5659b2a

DiegoAndai · 2024-07-10T21:36:43Z

Hey @Janpot @michaldudak, I need your help with this. Could you check the branch and see if you can figure it out?

We have two packages which are not compatible with React 19 types:

styled-components, dependency of @mui/styled-engine-sc
next@13, dependency of @mui/material-nextjs

Important note: Focus only on the styled-components/@mui/styled-engine-sc and next@13/@mui/material-nextjs packages. If you run typescript on the root, you'll see many emotion type errors. Those are being worked on separately on emotion-js/emotion#3206.

Here are the errors I'm getting:

`styled-components`

(error reference)

../../node_modules/.pnpm/[email protected][email protected][email protected]_wix7kfhaaslmbrv34cmdpqmtmy/node_modules/styled-components/dist/types.d.ts(133,189): error TS2503: Cannot find namespace 'JSX'.

For this one, I would like to pin the @types/react version in @mui/styled-engine-sc, but I'm not able to achieve it. The things I tried are

Use resolutions in @mui/styled-engine-sc package.json. Doesn't work: resolutions` is for the root package only

Add specific package resolution as such:

 "@mui/styled-engine-sc>@types/react": "18.3.3",
 "@mui/styled-engine-sc>@types/react-dom": "18.3.0",

but it doesn't seem to work either.

`next@13`

(error reference)

../../node_modules/.pnpm/[email protected]_@[email protected][email protected][email protected]_eyrhw4xacy4nwuqjvaiwg3fsum/node_modules/next/dist/shared/lib/utils.d.ts(158,59): error TS2503: Cannot find namespace 'JSX'.

For this one, I think we should deprecate the next@13 version of the package and turn off the typescript check, unless you have any suggestions on how to keep it working. I don't 😅.

DiegoAndai · 2024-07-10T21:45:00Z

Also, I would expect this line to exclude the ../../node_modules/... from the typescript check, but it seems it doesn't 🤔

JCQuintas · 2024-07-10T22:18:37Z

Going to sleep now, so can't help much, but got some points that might help you:

Also, I would expect this line to exclude the ../../node_modules/... from the typescript check, but it seems it doesn't 🤔

probably skipLibCheck: true on tsconfig can help here.

Use resolutions in @mui/styled-engine-sc package.json. Doesn't work: resolutions` is for the root package only

Resolutions is for yarn only, but we use pnpm, so you are probably looking at the wrong prop, you can use this instead

  "pnpm": {
    "overrides": {
      "@types/react": "18.3.3",
      "@types/react-dom": "18.3.0"
    }
  },

aarongarciah · 2024-07-11T07:53:42Z

@JCQuintas resolutions gets merged with pnpm.overrides, and since we only use resolutions, it works. From the pnpm docs:

Functionally identical to pnpm.overrides, this field is intended to make it easier to migrate from Yarn.

resolutions and pnpm.overrides get merged before package resolution (with pnpm.overrides taking precedence), which can be useful when you're migrating from Yarn and need to tweak a few packages just for pnpm.

JCQuintas · 2024-07-11T08:24:18Z

@JCQuintas resolutions gets merged with pnpm.overrides, and since we only use resolutions, it works. From the pnpm docs:

oops didn't know that. 🙃

DiegoAndai · 2024-07-11T12:39:57Z

probably skipLibCheck: true on tsconfig can help here.

Yes, skipLibCheck: true removes the warnings. I'm unsure if we want to use it (@mui/code-infra?). If there's a way for us to skip only these two stale library dependencies checks, that would be better than disabling it altogether. Feels like "throwing the baby out with the bath water".

JCQuintas · 2024-07-11T17:49:05Z

probably skipLibCheck: true on tsconfig can help here.

Yes, skipLibCheck: true removes the warnings. I'm unsure if we want to use it (@mui/code-infra?). If there's a way for us to skip only these two stale library dependencies checks, that would be better than disabling it altogether. Feels like "throwing the baby out with the bath water".

As far as I know there is no other way around this right now, since you can't select which libs to skip in typescript.

Since we are already doing the "resolutions" change, that is a "trust me" moment. Sure the lib check might help catching so issues, but if the types are different, then you will definitely get an error with the only opt out I know being skipLibCheck: true.

ref:
microsoft/TypeScript#30511

oliviertassinari · 2024-07-12T22:19:00Z

packages/mui-base/src/useSlider/useSlider.ts

@@ -267,7 +267,7 @@ export function useSlider(parameters: UseSliderParameters): UseSliderReturnValue

  const [focusedThumbIndex, setFocusedThumbIndex] = React.useState(-1);

-  const sliderRef = React.useRef<HTMLSpanElement>();
+  const sliderRef = React.useRef<HTMLSpanElement>(undefined);


Shouldn't it be?

Suggested change

const sliderRef = React.useRef<HTMLSpanElement>(undefined);

const sliderRef = React.useRef<HTMLSpanElement>(null);

It should be an immutable ref here. It looks like I have missed this one in #38762. We could make a PR just for it.

I dove a bit into this in mui/mui-x#11847.

Oh, ok, it's changing: DefinitelyTyped/DefinitelyTyped#64896, so

Suggested change

const sliderRef = React.useRef<HTMLSpanElement>(undefined);

const sliderRef = React.useRef<HTMLSpanElement | null>(null);

?

I think | null is the correct approach, yeah #42881 (comment)

Right, then +1 to udpate all the codebase with this. We don't have to correlate it with React 19..it seems that it would work with all versions.

For posterity, in React 19:

React.useRef requires an initial value. There's no need to do | null when the initial value is null (same for undefined). You can still do it if you want to be more explicit. It goes like this (pseudo-code):

const ref = React.useRef<T>(null) -> ref is T | null

const ref = React.useRef<T>(undefined) -> ref is T | undefined

const ref = React.useRef<T>(T) -> ref is T

React.MutableRefObject has been deprecated. React.RefObject is used for all cases now, and it's always mutable. Unlike React.Ref, we need to explicitly make the ref object nullable: React.RefObject<T | null>.

(more info in the React 19 types PR)

Janpot · 2024-07-16T09:36:39Z

The things I tried are

I'll try to take a look at this over the week, but what I can already say about resolutions is that I don't think of it as a tool we can use to solve this problem. As far as I'm aware, as a package author, you can't enforce how your transitive dependencies are resolved by the consumers of your package. So we'd fix the problem in our repo, but I believe our users would still have it.

I think we shouldn't use resolutions/overrides, unless it's scoped to the docs workspace.

edit:
It looks like styled-components doesn't have a (peer)dependency on @types/react, so I guess that means there is nothing to override. I think I got it working with the following steps:

npm patch styled-components
open the package in code editor, edit the package.json to add to the peer dependencies:
```
"@types/react": "*",
"@types/react-dom": "*"
```
commit the patch
pnpm install --force

Not 100% clear to me yet what exactly is going on here. It's referencing react in its types without specifying react types as a peerDependency. Do we need to open PR with styled-components for this?

DiegoAndai · 2024-07-18T19:36:02Z

Thanks for taking a look @Janpot

I don't think of [resolutions] as a tool we can use to solve this problem

With this, do you mean that we shouldn't have @types/react and @types/react-dom in the resolutions? Or that we cannot use them for the styled-components issue in particular?

I tried the patch approach but I still get the same errors 😓

The issue here is that I'm not able to figure out how to make the pnpm workspace like this:

Use the React 19 types for most packages
Use React 18 types for mui-styled-engine-sc, or if not possible, do not test these types at all. We can deprecate this package or have a warning that it doesn't work with React 19, as I don't see them supporting React 19 anytime soon. This is the error we're trying to solve: reference
Use React 18 types for next@13 inside the mui-material-nextjs package, or if not possible, do not test these types at all. We can deprecate the next@13 version of mui-material-nextjsor have a warning that it doesn't work with React 19. This is the error we're trying to solve: reference

Do you see a way of making it work like that?

oliviertassinari · 2024-07-18T21:23:00Z

deprecate @mui/styled-engine-sc as well as the next@13 version of @mui/material-nextjs

This feels a bit too bold. I could see a lot of people using styled-components and not care about types, as well as upgrading Material UI to v6 without upgrading React or Next.js. If we can ignore the types for those packages, I think it would be good enough.

Janpot · 2024-07-19T09:32:27Z

I tried the patch approach but I still get the same errors

I'm taking a closer look today

With this, do you mean that we shouldn't have @types/react and @types/react-dom in the resolutions?

Correct, in fact we shouldn't have resolutions at all, resolutions are a bad idea, especially for library authors like us. Packages declare which dependency range they are compatible with, and the resolutions field instructs package managers to ignore that and supply another version that may or may not be compatible. Why would we expect this to just work? Moreover, this only happens inside of our repo, our users would get the transitive dependency installed the same way as if resolutions didn't exist. If pnpm dedupe doesn't dedupe it, something needs to be fixed at the dependency level, not faked with resolutions. It may work if you're building applications, but not when you're publishing libraries.

@emotion/... related type problems: I'm assuming them to be covered by emotion-js/emotion#3206. What I'm further changing in this PR:

Remove resolutions for @types/react. add a specific one that points @types/react inside of types-react-dom to types-react@19.... To be removed after @types/react@19 is released.
Add a resolution for @types/react in @types/hoist-non-react-statics. The latter has dependency of @types/react: * so this should be fine, to be removed after @types/react@19 is released.
patch styled-components to remove deprecated namespace. This patch needs to be proposed to styled-components repository and published to npm in a future version. All it needed is not accessing the global JSX namespace. I've seen them mix JSX. and React.JSX. so this shouldn't break any compatibility for them. update: relevant PR
@mui/material-nextjs ~~(still investigating)~~ This package has a peer dependency on next: 13 || 14. Both of which don't support React 19. Assuming that when users have any of these as a peer dependency, they're not using react 19 neither. The errors we see come from us adding v13 as a dev dependency, which I believe we do specifically for type checking. We can upgrade it to v15.0.0-canary.73 to make the errors go away, the end-users will be unaffected. Since this package basically depends on "whatever version the user has installed", there is no correct answer for this dev dependency. We're going to type check against react 19 types, so a a version of next that is compatible with React 19 types makes most sense to me.
docs ~~(still investigating)~~ I think I have most non emotion issues by resolving @types/react dependency of @types/react-swipable-views and @types/react-window

Janpot · 2024-10-08T13:51:58Z

I just added a patch for styled-components types

Will you also open a PR with styled-components? The patch is good to unblock this PR, but we can't merge it to master.

aarongarciah · 2024-10-08T14:07:14Z

Will you also open a PR with styled-components?

That's the idea, although I haven't looked into how to solve the issue on styled-component's side. I'll open an issue nevertheless.

aarongarciah · 2024-10-08T14:59:27Z

941e213 fixes the ref type error in the Timeline component. I extracted it to a separate PR: #44043

This reverts commit cc982ff.

aarongarciah · 2024-10-08T16:23:27Z

I opened an issue in the styled-components repo regarding the JSX deprecated namespace being used in the generated withTheme.d.ts file: styled-components/styled-components#4359

I'll try to open a PR with a potential fix.

DiegoAndai · 2024-10-08T18:08:34Z

The patch is good to unblock this PR, but we can't merge it to master.

@Janpot I wonder why. I know it's not ideal, but what if React 19 releases before styled-components fixes the issue? Would you be against using the patch in that situation as well?

Janpot · 2024-10-09T07:52:56Z

I wonder why.

Because end-users wouldn't get this patch, so they'd still see the typing errors. But yeah, we can probably relax as this is only a dependency of @mui/styled-engine-sc, let's not go overboard on this then and tell users to just use skipLibCheck.

aarongarciah changed the title ~~Bump React to 19~~ [core] Bump React to 19 Jul 2, 2024

aarongarciah added dependencies Update of dependencies React 19 support PRs required to support React 19 labels Jul 2, 2024

aarongarciah self-assigned this Jul 2, 2024

aarongarciah requested a review from DiegoAndai July 2, 2024 15:57

aarongarciah force-pushed the react-19 branch from b6b0b8d to 81cea02 Compare July 3, 2024 07:03

github-actions bot added PR: out-of-date The pull request has merge conflicts and can't be merged and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Jul 3, 2024

aarongarciah force-pushed the react-19 branch from cf4c057 to 0e36678 Compare July 5, 2024 07:01

github-actions bot added PR: out-of-date The pull request has merge conflicts and can't be merged and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Jul 5, 2024

github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 10, 2024

github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 11, 2024

oliviertassinari reviewed Jul 12, 2024

View reviewed changes

Janpot mentioned this pull request Jul 19, 2024

Replace deprecated global JSX namespace styled-components/styled-components#4333

Merged

aarongarciah mentioned this pull request Oct 8, 2024

[lab][Timeline] Fix types for React 19 #44043

Merged

aarongarciah and others added 20 commits October 8, 2024 17:17

Bump React to 19

369c230

Run useRef codemod

0fce693

Remove resolutions for @types/react

91803b0

patch deps

73c1cc4

docs

1de7c1a

Update some React refs types and default values

9e858c5

Stop using deprecated React.MutableRefObject

2a3e5c0

Fix next types

1d5a94f

Fix remaining element.ref access issues

7f15351

Remove stale util

63aad34

Fix Modal test

7a03c0d

Undo some React.MutableRefObject changes

2d1241d

Revert "Fix Modal test"

f42adaa

This reverts commit cc982ff.

Adapt Modal test to pass

ced416f

Update @floating-ui transitive dependencies

d1ee2ee

Update Next.js

b6169a4

Disable Next.js workerThreads

1100354

Adapt envinfo test to pass

032cfc3

pnpm dedupe

c603f89

Patch styled-components types

5659b2a

aarongarciah force-pushed the react-19 branch from 941e213 to 5659b2a Compare October 8, 2024 15:17

aarongarciah mentioned this pull request Oct 8, 2024

Cannot find namespace 'JSX' error when using React 19 types styled-components/styled-components#4359

Open

github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Oct 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[core] Bump React to 19 #42824

[core] Bump React to 19 #42824

aarongarciah commented Jul 2, 2024 •

edited

Loading

DiegoAndai commented Jul 9, 2024

aarongarciah commented Jul 10, 2024

mui-bot commented Jul 10, 2024 •

edited

Loading

DiegoAndai commented Jul 10, 2024 •

edited

Loading

DiegoAndai commented Jul 10, 2024

JCQuintas commented Jul 10, 2024

aarongarciah commented Jul 11, 2024 •

edited

Loading

JCQuintas commented Jul 11, 2024

DiegoAndai commented Jul 11, 2024 •

edited

Loading

JCQuintas commented Jul 11, 2024

oliviertassinari Jul 12, 2024

oliviertassinari Jul 12, 2024

aarongarciah Jul 15, 2024

oliviertassinari Jul 18, 2024

aarongarciah Jul 26, 2024

Janpot commented Jul 16, 2024 •

edited

Loading

DiegoAndai commented Jul 18, 2024 •

edited

Loading

oliviertassinari commented Jul 18, 2024

Janpot commented Jul 19, 2024 •

edited

Loading

Janpot commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

DiegoAndai commented Oct 8, 2024 •

edited

Loading

Janpot commented Oct 9, 2024 •

edited

Loading

	const sliderRef = React.useRef<HTMLSpanElement>(undefined);
	const sliderRef = React.useRef<HTMLSpanElement>(null);

[core] Bump React to 19 #42824

Are you sure you want to change the base?

[core] Bump React to 19 #42824

Conversation

aarongarciah commented Jul 2, 2024 • edited Loading

DiegoAndai commented Jul 9, 2024

aarongarciah commented Jul 10, 2024

mui-bot commented Jul 10, 2024 • edited Loading

Netlify deploy preview

Bundle size report

DiegoAndai commented Jul 10, 2024 • edited Loading

styled-components

next@13

DiegoAndai commented Jul 10, 2024

JCQuintas commented Jul 10, 2024

aarongarciah commented Jul 11, 2024 • edited Loading

JCQuintas commented Jul 11, 2024

DiegoAndai commented Jul 11, 2024 • edited Loading

JCQuintas commented Jul 11, 2024

oliviertassinari Jul 12, 2024

Choose a reason for hiding this comment

oliviertassinari Jul 12, 2024

Choose a reason for hiding this comment

aarongarciah Jul 15, 2024

Choose a reason for hiding this comment

oliviertassinari Jul 18, 2024

Choose a reason for hiding this comment

aarongarciah Jul 26, 2024

Choose a reason for hiding this comment

Janpot commented Jul 16, 2024 • edited Loading

DiegoAndai commented Jul 18, 2024 • edited Loading

oliviertassinari commented Jul 18, 2024

Janpot commented Jul 19, 2024 • edited Loading

Janpot commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

aarongarciah commented Oct 8, 2024

DiegoAndai commented Oct 8, 2024 • edited Loading

Janpot commented Oct 9, 2024 • edited Loading

aarongarciah commented Jul 2, 2024 •

edited

Loading

mui-bot commented Jul 10, 2024 •

edited

Loading

DiegoAndai commented Jul 10, 2024 •

edited

Loading

`styled-components`

`next@13`

aarongarciah commented Jul 11, 2024 •

edited

Loading

DiegoAndai commented Jul 11, 2024 •

edited

Loading

Janpot commented Jul 16, 2024 •

edited

Loading

DiegoAndai commented Jul 18, 2024 •

edited

Loading

Janpot commented Jul 19, 2024 •

edited

Loading

DiegoAndai commented Oct 8, 2024 •

edited

Loading

Janpot commented Oct 9, 2024 •

edited

Loading