@mui/material upgrade from 5.10.1 to 5.10.9 breaks our app

[frontyard]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

We are using ~5.10.1 in our package.json

The latest patch version was deployed which was 5.10.9 and something in between those two patch versions is not a patch.

Looking further into release log, at least one patch version (5.10.9) has breaking changes in it. Should we not assume semver conventions for MUI releases?

Current behavior 😯

Patch upgrade has breaking changes.

Expected behavior 🤔

Patch upgrade should not have breaking changes.

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[Nikhil562]

I would love to do that , can you please assign to me

[oliviertassinari]

@frontyard Do you have a reproduction? We won't be able to act on this feedback without.

---

Looking further into release log, at least one patch version (5.10.9) has breaking changes in it. Should we not assume semver conventions for MUI releases?

This is likely unrelated. What you see in https://github.com/mui/material-ui/releases/tag/v5.10.9 is impacting an unstable_ prefixed module, and per https://mui.com/versions/#what-doesnt-count-as-a-breaking-change it doesn't count for semver.

Now, I agree, I had the same thought initially when I read the changelog. I think that we could make it clearer that it's about a breaking change on an unstable API.

[ccromnow]

I understand the relation to unsafe_ breaking changes not being reflected by minor or major versions for external users, however when you do that in internal packages it causes problems for shared environments.

Short example of environment:
Shared dependencies using Webpack Federated Modules.
Theming is done in a central module that loads parts of the application as federated modules.
In order to make the theming work for the loaded parts, the @mui/styled-engine package needs to be a shared dependency.
This means that the central module will decide what version of @mui/styled-engine is shared to all loaded modules.
In the environment all packages of @mui are dependencies in a shared design component library that, when installed, loads the latest patch version of every package.

The problem arises when there exists breaking changes between packages inside @mui/ as some of those packages are shared and others are not.
As the core module and the federated modules are built separately and at any time a new breaking change inbetween the packages causes the application to crash when the “shared part of the @mui/” has breaking changes to the parts that are dragged in in the built packages.

The way forward for us would be one of the following:
Solution 1:
If the @mui/ packages themselves are relying on unsafe_ functions that would not be the same as an external package, and changes that causes breaking behavior in between packages are at least a minor version. This would be by far the most preferred solution.

Solution 2:
All @mui packages needs to be shared dependencies, this is not optimal as it slows down run time quite a bit and will break as soon as a new package is introduced and functionality is moved to that package in the same manner as current breaking changes.

Solution 3:
All @mui packages needs to be locked at top level and patch versions have to be treated the same as minor and major versions, also not optimal as bugs and everything needs to be synced. And also when deployed all depending modules needs to be deployed in synchronization with the core package, losing a lot of the benefits from the shared enviroment.

[siriwatknp]

Solution 1:
If the @mui/ packages themselves are relying on unsafe_ functions that would not be the same as an external package, and changes that causes breaking behavior in between packages are at least a minor version. This would be by far the most preferred solution.

Solution 1 seems to be the way that we can start doing this in the future without changing too much. I will keep this in mind for sure.

[siriwatknp]

For the original issue, I'd say that it is the expected behavior so I'm closing the issue (unless the author meant a different error apart from the BREAKING CHANGE)

[oliviertassinari]

I agree with @siriwatknp. "Current behavior 😯 Patch upgrade has breaking changes." is the expected behavior. I have updated #34639 to be clearer, it doesn't impact a stable API (it imports an unstable API).