[pickers] Incomplete `peerDependencies` break usage with `yarn pnp`

[nate-summercook]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Current behavior 😯

Yarn PnP (Plug'n'Play) is more strict when it comes to specifying a library's peerDependencies / dependencies correctly. Currently, @mui/x-date-pickers is missing the following entries in peerDependencies:

• @babel/runtime
• @emotion/react (because it's a peer dependency of @mui/system)
• @emotion/styled (because it's a peer dependency of @mui/system)

This results in errors like this one:

ERROR in resolving fallback for shared module @emotion/react
Module not found: Error: @mui/styled-engine tried to access @emotion/react (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: @emotion/react
Required by: @mui/styled-engine@virtual:7a413bb353e548319c90adb82631b0c089acd1a802fdcf34c7a70f0d92986c9f29874633545bb7dc3d02df8b9ae9870617074e94e1a662f0e58596867aac2836#npm:5.6.1 (via /workspace-path/.yarn/__virtual__/@mui-styled-engine-virtual-d4f5f5ea46/0/cache/@mui-styled-engine-npm-5.6.1-06c551ec66-cd17d05902.zip/node_modules/@mui/styled-engine/StyledEngineProvider/)

Ancestor breaking the chain: @mui/lab@virtual:be640854c908ca72c5c45d17e3a5d76a2c579538ed551547b39edc486c90638abf94c25a34fa05a0a9167f796b8fb98e280e0bad9b44c61172fe75f4bcf39869#npm:5.0.0-alpha.80
Ancestor breaking the chain: @mui/x-date-pickers@virtual:a642cd9791514da72a2616a56d7e5a3388c1c9ae1ff46c38c21105bc127f858e9e9b8bf21f1f43f2292c03fb16041526691dbd0ab6f7ba072e2c24ae04f50e11#npm:5.0.0-alpha.2

Expected behavior 🤔

If the mentioned packages were added to peerDependencies, these errors would not occur with yarn pnp.

Steps to reproduce 🕹

Steps:

1. Set up a new react app (i.e. via CRA) npx create-react-app mui-x-date-pickers
2. Make sure you have yarn installed
3. run yarn set version berry in order to get the latest yarn version with pnp
4. run yarn add @mui/x-date-pickers @mui/material @mui/system
5. Implement usage of one of these date pickers:

   
   import {CalendarPicker} from '@mui/x-date-pickers';

function App() { const handleDateChange = () => { };

return ( <CalendarPicker date={null} onChange={handleDateChange} /> ); }

export default App;

6. start the app --> errors appear.

### Context 🔦

I'm in an environment where I rely heavily upon yarn functionalities (yarn workspaces, pnp, etc.). This issue is a major blocker for me.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

System: OS: macOS 12.3.1 Binaries: Node: 16.11.1 - /opt/javascript/ncanode/16.11.1/node/bin/node Yarn: 3.2.0 - /opt/javascript/ncayarn/1.22.4/bin/yarn npm: 8.0.0 - /opt/javascript/ncanode/16.11.1/node/bin/npm Browsers: Chrome: 101.0.4951.54 Edge: Not Found Firefox: 99.0.1 Safari: 15.4 Browser used: Brave [Version 1.37.116 Chromium: 100.0.4896.127 (Official Build)]

</details>

### Order ID 💳 (optional)

_No response_

[nate-summercook]

I can also create a pull request if that helps :)

[DanailH]

I can also create a pull request if that helps :)

Thank you @nate-summercook. Contributions are always appritiated. I'm looping in @flaviendelangle as there may be complications based on the package you would like to contribute to as not all of them are MIT.

[nate-summercook]

Here's a related issue (follow-up of this one): https://github.com/mui/material-ui/issues/32620

[nate-summercook]

Thanks for the support :)

[flaviendelangle]

Your welcome It should be released next week :+1:

[nate-summercook]

Cool, is someone looking at the related PR? :)

[flaviendelangle]

Not yet no

[liamlows]

so until this is added @flaviendelangle we would need to add babel/runtime as a peer dep?

Also, a little off topic but is there any intention to move towards SWC and away from babel with MUI?

Thanks!

[flaviendelangle]

so until this is added @flaviendelangle we would need to add babel/runtime as a peer dep?

Not sure, I never user yarn pnp, but we should release in a few days.

Also, a little off topic but is there any intention to move towards SWC and away from babel with MUI?

Not that I am aware off, why ?

[liamlows]

Also, a little off topic but is there any intention to move towards SWC and away from babel with MUI?

Not that I am aware off, why ?

I'm fairly new to dealing with babel and SWC but from my understanding SWC is about 20x faster than Babel and also decreases overall size of the repo and code sent to client. I dont know how much that affects the runtime for babel since a lot of the cost is in compilation and with production builds that's all done in advance, but still, I have transitioned our whole codebase out of babel and trying to keep it that way haha.

[flaviendelangle]

SWC is about 20x faster than Babel

Yes, on our side SWC would most likely be a lot faster. However we use a good amount of babel plugins and I don't know how mature is the SWN ecosystem. With that being said, if we can migrate one day, I will be in favor of doing it.

decreases overall size of the repo and code sent to client

I am curious about that one Unless babel is doing something terribly wrong, I guess decrease in runtime size comes from less support from older browser. Something a product like ours must be very careful with.

It is clearly something we will investigate some day :+1: