[core] Remove outdated babel proposal plugins

[kkocdko]

Close #36794

• I have followed (at least) the PR section of the contributing guide.

https://deploy-preview-36795--material-ui.netlify.app/

[kkocdko]

Why the CircleCI failed by you may have revoked the CircleCI OAuth app...

[kkocdko]

Hi there?

[mui-bot]

Netlify deploy preview

https://deploy-preview-36795--material-ui.netlify.app/

@material-ui/core: parsed: -3.65% 😍, gzip: -3.68% 😍
@material-ui/lab: parsed: -2.86% 😍, gzip: -2.94% 😍
@material-ui/system: parsed: -1.37% 😍, gzip: -1.20% 😍
@material-ui/unstyled: parsed: -3.10% 😍, gzip: -2.50% 😍
@mui/material-next: parsed: -1.82% 😍, gzip: -1.91% 😍
@mui/joy: parsed: -2.69% 😍, gzip: -2.69% 😍

Bundle size report

Details of bundle changes

Generated by 🚫 dangerJS against b4ece98

[ZeeshanTamboli]

@kkocdko It's a great first pull request at MUI. Thanks a lot!

For others to see:

• class-properties and private-methods were supported by default in babel-preset-env in 7.14.0: https://babel.dev/blog/2021/04/29/7.14.0

you can remove @babel/plugin-proposal-class-properties and @babel/plugin-proposal-private-methods, since they are now enabled by default in @babel/preset-env.

• private-property-in-object was supported by default in 7.15.0 - https://babel.dev/blog/2021/07/26/7.15.0
• object-rest-spread is also included in ES2018: Add initial support for ES2018 in preset-env babel/babel#7658.

[oliviertassinari]

This seems to break Safari compatibility: https://mui.com/material-ui/getting-started/supported-platforms/#browser, or at minimum the CI is always red now:

https://app.circleci.com/pipelines/github/mui/material-ui/97978/workflows/05b23843-04a8-4c78-950c-e64963c5473d/jobs/521556

I think that we need to fix this. I landed here from https://www.notion.so/mui-org/KPIs-1ce9658b85ce4628a2a2ed2ae74ff69c?pvs=4#f3c0c606c62148f1bd06784f367bd8c4

[michaldudak]

These test run on Safari 13.1.2, which we do not support.
I'll update the pipeline to use the browsers we claim to target.

[ZeeshanTamboli]

We run the browser tests in master branch on Safari 13.1.2, while in the documentation we mention to support Safari (macOS) >=14. Also in .browserslistrc it is 14. There is a discrepancy. Also, to catch such issues, should we run tests in the Safari browser on other branches apart from the master branch as well?

[michaldudak]

Also, to catch such issues, should we run tests in the Safari browser on other branches apart from the master branch as well

Agree. They should be run on PRs to be visible. @oliviertassinari, would it significantly impact us financially if we enabled BrowserStack tests on each PR?

[oliviertassinari]

The docs says we support Safari from v12.5: https://mui.com/material-ui/getting-started/supported-platforms/#browser

which I believe is the same between browsers and mobiles.

would it significantly impact us financially if we enabled BrowserStack tests on each PR?

No impact, we have a community plan. The main limit is the resources available in BrowserStack under this plan. https://www.browserstack.com/accounts/profile

We could also maybe use LambdaTest, they were happy to sponsor us: https://www.notion.so/mui-org/Accounts-945f0ccb9f7749ccb9e84b9eb9b13ec7?pvs=4#9be9ee4c9a5f428fabd98a67d0825cc3

However, there are browsers that we run in BrowserStack that we could run directly inside the CircleCI runtime, maybe inside a local Selenium instance. Safari seems to the be only one that needs BrowserStack. I moved Firefox to Circle CI runtime with #34764. This PR comes with the cost of no longer testing the right version of Firefox. I suspect that the real solution is with Docker.

---

One thing that could work is to run it based on a modulo of the PR number. Like for 1/3 of the PR and see how it goes. But then, we need a way to run it on a case by case for PRs, e.g. for PRs like this one.

[michaldudak]

One thing that could work is to run it based on a modulo of the PR number. Like for 1/3 of the PR and see how it goes. But then, we need a way to run it on a case by case for PRs, e.g. for PRs like this one.

How about we enable BrowserStack on all PRs (and perhaps disable them on master) and see what is the impact, then we can adjust if necessary?

[oliviertassinari]

How about we enable BrowserStack on all PRs (and perhaps disable them on master) and see what is the impact, then we can adjust if necessary?

@michaldudak This is how we used to do it in the past. No objections. I'm not aware of fundamental changes that would make it work this time, so I think it's great to fully experience the problem, as a first step toward a solution.

[gmferise]

It does not seem that the object-rest-spread polyfill is functional after this merge. Here is a diff from the npm package between 5.12.3 and 5.13.1. This affects @mui/utils and @mui/private-theming.

[oliviertassinari]

@gmferise Note that this PR was partially released in v5.13.1. Then it was reverted with #37331 but only partially released with v5.13.2, as you pointed out, not all the packages were released.

Are you facing a specific problem?

[gmferise]

@oliviertassinari It did cause me some issues, but I was able to work around them. My understanding was that this PR removed the plugins because the resulting polyfills were already included / could be enabled without them. I thought the extra info that object-rest-spread is not functional would help to fix the Safari compatibility.