[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

AvatarGroup: parsed: -1.22% 😍, gzip: -1.09% 😍
ImageListItem: parsed: -1.34% 😍, gzip: -1.20% 😍
ToggleButtonGroup: parsed: -1.30% 😍, gzip: -1.18% 😍
BottomNavigation: parsed: -1.35% 😍, gzip: -1.21% 😍
MenuList: parsed: -1.30% 😍, gzip: -1.13% 😍
Accordion: parsed: -1.12% 😍, gzip: -0.98% 😍
@material-ui/core: parsed: -0.15% 😍, gzip: -0.11% 😍
TextField: parsed: -0.53% 😍, gzip: -0.32% 😍
@material-ui/lab: parsed: -0.28% 😍, gzip: -0.18% 😍
TabList: parsed: -0.79% 😍, gzip: -0.43% 😍
Breadcrumbs: parsed: -0.85% 😍, gzip: -0.44% 😍
SpeedDial: parsed: -0.80% 😍, gzip: -0.42% 😍

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against efb3518

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

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.

Janpot · 2024-11-13T17:28:47Z

btw, for us I would consider the same thing, instead of the patch, enable skipLibCheck on @mui/styled-engine-sc.

DiegoAndai · 2024-11-13T17:40:37Z

@Janpot should I enable skipLibCheck on @mui/styled-engine-sc and remove the patch?

Janpot · 2024-11-13T17:47:03Z

If that works. The advantage would be that we isolate the hack a bit more to @mui/styled-engine-sc. If it doesn't work I wouldn't waste too much time on it for now.

DiegoAndai · 2024-11-13T18:41:33Z

If that works.

It's working locally 👍🏼 I'll need to check the CI builds "killed" signal issue, but it should also work in CI.

DiegoAndai · 2024-11-15T13:56:58Z

Given the amount of dependency changes, medium sized containers receive the "killed" signal on CI. I temporarily changed the test_checkout to medium+ and it succeeded. With that, we can also run test_browser and test_types which already use medium+, and both are succeeding. I'll be using those for the moment.

When the time comes to merge this, we can change all test containers to medium+, and then change it back in a follow up PR. I don't know if there's an easier way to achieve this cc: @mui/code-infra, please let me know if there is.

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 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

DiegoAndai mentioned this pull request Nov 7, 2024

Bump next to v15.0.3 #44311

Open

1 task

Merge branch 'master' into react-19

9c37cac

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

DiegoAndai added 2 commits November 12, 2024 15:47

Pin next to 15.0.2 temporarily

06e3c34

Trigger CI

e2637d4

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

Merge branch 'master' into react-19

0e34c2c

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 Nov 13, 2024

Merge branch 'master' into react-19

6434117

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

DiegoAndai added 2 commits November 13, 2024 12:56

Update material-nextjs next version to canary

5e06d10

Update to latest React rc

2f3487d

DiegoAndai added 2 commits November 13, 2024 15:00

Use skipLibCheck instead of sc patch

99ef5eb

Trigger CI

b40b413

DiegoAndai added 2 commits November 15, 2024 10:39

Update React to 19.0.0-rc.1

8239a6e

Try medium+ container to see if killed signal is due to OOM

efb3518

DiegoAndai mentioned this pull request Nov 15, 2024

[material-ui] Backport React 19 changes to Material UI v5 #44413

Open

33 tasks

github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 15, 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

aarongarciah commented Oct 8, 2024

DiegoAndai commented Oct 8, 2024 •

edited

Loading

Janpot commented Oct 9, 2024 •

edited

Loading

Janpot commented Nov 13, 2024 •

edited

Loading

DiegoAndai commented Nov 13, 2024

Janpot commented Nov 13, 2024

DiegoAndai commented Nov 13, 2024

DiegoAndai commented Nov 15, 2024

	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

aarongarciah commented Oct 8, 2024

DiegoAndai commented Oct 8, 2024 • edited Loading

Janpot commented Oct 9, 2024 • edited Loading

Janpot commented Nov 13, 2024 • edited Loading

DiegoAndai commented Nov 13, 2024

Janpot commented Nov 13, 2024

DiegoAndai commented Nov 13, 2024

DiegoAndai commented Nov 15, 2024

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

Janpot commented Nov 13, 2024 •

edited

Loading