Skip to content

[core] Use MUI Core v7 libraries in packages and docs #16771

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 35 commits into from
Mar 18, 2025

Conversation

DiegoAndai
Copy link
Member

@DiegoAndai DiegoAndai commented Feb 28, 2025

Changelog

  • The peer dependency on @mui/material has been updated to accept only v7.
    This has been done to increase the adoption rate of ESM.
    Since only v7 of @mui/material has proper ESM support, we decided to help with its adoption and fix numerous issues using X packages in environments where transpiling is not an option.

TODO

  • Add a common migration page/section once we agree on the changes/direction

@DiegoAndai DiegoAndai self-assigned this Feb 28, 2025
@DiegoAndai DiegoAndai force-pushed the material-ui-v7-beta-test branch from 527020b to 0f035a8 Compare February 28, 2025 19:17
Copy link

github-actions bot commented Mar 4, 2025

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 4, 2025
@DiegoAndai
Copy link
Member Author

The deploy, codesandbox, and types failures should be fixed with mui/material-ui#45491

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 11, 2025
@DiegoAndai
Copy link
Member Author

DiegoAndai commented Mar 11, 2025

@Janpot @cherniavskii @LukasTy in the last commit, I fixed some TS issues that surfaced:

I wonder why these weren't caught earlier 🤔 any ideas?

After fixing these, we have two types errors left, which are being handled in mui/material-ui#45548

I think we should split these fixes off into separate PRs, but wanted to check with you first.

Copy link
Member

@LukasTy LukasTy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this! 🙏
The changes make sense to me. 👌

@@ -388,11 +388,11 @@ function transformInputProps(props: GridSlotProps['baseInput'] | undefined) {
result.endAdornment = <InputAdornment position="end">{result.endAdornment}</InputAdornment>;
}

if (slotProps?.htmlInput) {
if (slotProps?.input) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the change in gridBaseSlots might be a slight breaking change, which should be flagged. 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where should I do that?
Also, should I start creating separate PRs for each of these fixes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @mui/xgrid could assert it and handle it accordingly? 🤔
It looks like this might have been a mistake all along. 🙈

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What slotProps should be used for the HTML input element? Did it change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • In the Input components, slotProps.input points to the input HTML element
  • In the TextField component, slotProps.htmlInput points to the input HTML element, and slotProps.input to the Input component

It hasn't changed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. So the slotProps here aren't material slotProps, they're data-grid baseInput slotProps which have their own independent set of typings. I didn't notice that nuance in material props when I wrote the grid base slot typings, so I made htmlInput refer to the HTML input element for both baseInput and baseTextField.

The grid base slots are inspired by material API but don't match it in many places. It's possible that we keep using htmlInput in both cases, and I think it's going to be more intuitive for grid-bindings authors reading those typings, so I'd keep it as it is. Any thoughts on that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying. 👍
Yeah, it makes sense to me, in such case, the changes made by Diego should be reverted. 👌

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we have a problem if we revert this change.
Docs examples with Material components start failing prop checking, because they do not expect to receive slotProps.htmlInput on a InputBase slot. 🙈
So, this also potentially means a BC for users if we go with some sort of override. 🤔

Either we need to rename the slotProps to input as initially done by Diego or consider alternative typing approaches. 🤷
WDYT @romgrk? Does the current state make sense?
InputBase component never had a htmlInput slot, it was always input, so, if I understand it correctly, material migrating to slotProps triggered this error as now the typing is very close, but different, while before there were no slotProps. 🤔

Copy link
Contributor

@romgrk romgrk Mar 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

material migrating to slotProps triggered this error as now the typing is very close, but different

In this case it's close but different, but in other cases it's completely different.

Docs examples with Material components start failing prop checking, because they do not expect to receive slotProps.htmlInput on a InputBase slot.

Why is an InputBase receiving those props though? The grid baseInput is not an InputBase, typecheck should not fail. Which examples are failing?

edit: I've found the issue, let me get some feedback from the rest of the team.

@Janpot
Copy link
Member

Janpot commented Mar 12, 2025

The changes in screenshots seem innocent, but do we know what in this PR caused them?

@LukasTy
Copy link
Member

LukasTy commented Mar 12, 2025

The changes in screenshots seem innocent, but do we know what in this PR caused them?

Please try merging the latest master to see if that fixes it. 😉
We recently merged a playwright package bump with a similar number of differences. 🤔

@LukasTy
Copy link
Member

LukasTy commented Mar 12, 2025

The changes in screenshots seem innocent, but do we know what in this PR caused them?

Please try merging the latest master to see if that fixes it. 😉 We recently merged a playwright package bump with a similar number of differences. 🤔

Maybe it's the bump of @mui/material in the demos that is causing these argos diffs? 🤔

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 12, 2025
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@LukasTy LukasTy added core Infrastructure work going on behind the scenes enhancement This is not a bug, nor a new feature breaking change v8.x and removed test labels Mar 14, 2025
@LukasTy LukasTy assigned LukasTy and unassigned DiegoAndai Mar 14, 2025
@LukasTy LukasTy marked this pull request as ready for review March 14, 2025 15:34
@LukasTy LukasTy requested review from Janpot and a team March 14, 2025 15:40
@@ -53,8 +53,8 @@
"peerDependencies": {
"@emotion/react": "^11.9.0",
"@emotion/styled": "^11.8.1",
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-alpha",
"@mui/system": "^5.15.14 || ^6.0.0 || ^7.0.0-alpha",
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-beta",
Copy link
Member

@Janpot Janpot Mar 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to already define the full v7 range so that we don't have to make changes to test with stable core once it gets release. We then just have to remove ^7.0.0-beta once X goes stable.

Suggested change
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-beta",
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0 || ^7.0.0-beta",

🤔 I believe we can do this both for dependencies and peer dependencies

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, somehow I might have missed something. 🙈
Clearly, I agree with the proposal. 👌

Copy link
Member

@Janpot Janpot Mar 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I'm just still wondering about the dev dependencies. I feel like we should think about how this will look in stable v7 world. i.e. every time we'd write

"@mui/material": "^7.3.8"

we'd want that to look like

"@mui/material": "^7.0.0"

At the time of X@v8 going stable. And thus today, in beta, we want that to look like

"@mui/material": "^7.0.0 || ^7.0.0-beta"

or

"@mui/material": "^7.0.0 || ^7.0.0-beta.4"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it matter that much if we plan to remove the beta dep after a stable release?
Technically, we could have probably left ^7.0.0-alpha.0 to be precise, if there are no specific fixes afterwards, that would prevent interoperability. 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not as important as it's not user facing. We can update it as well when core@v7 becomes stable.

Copy link
Member

@Janpot Janpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestion about widening the dependency range a bit more, otherwise looking good

Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 16, 2025
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 17, 2025
@LukasTy LukasTy merged commit 6a7113b into mui:master Mar 18, 2025
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change core Infrastructure work going on behind the scenes enhancement This is not a bug, nor a new feature v8.x
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants