Reexport createSvgIcon from utils

[siriwatknp]

Preview: https://codesandbox.io/s/joy-cra-typescript-forked-6fsov0?file=/src/App.tsx

This PR does the same as Material UI by exporting createSvgIcon from utils, so that the consumer can use yarn resolutions.

---

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

[mui-bot]

	Messages
📖	Netlify deploy preview: https://deploy-preview-35404--material-ui.netlify.app/

No bundle size changes

Generated by 🚫 dangerJS against e1cd264

[michaldudak]

Could we define @mui/joy as a peerDependency (marked as optional in peerDependenciesMeta) and change @mui/material to be optional as well? Then, at runtime, we check which one exists and use it (throwing an error when both are absent). This wouldn't require any actions from developers.

[mnajdova]

It may be a bit of overengineering in my opinion :)

What if, we move the SvgIcon & createSvgIcon inside the icons package and have a default for each them value used (we could use hardcoded values from the Material UI theme). Then, we can allow people to override these things trough the theme, wither by defining some specific tokens in the theme, or via style overrides (whatever we think would work better). There shouldn't be any breaking changes in terms of using it with Material UI as the defaults would be the same as they were before.

[siriwatknp]

Could we define @mui/joy as a peerDependency (marked as optional in peerDependenciesMeta) and change @mui/material to be optional as well? Then, at runtime, we check which one exists and use it (throwing an error when both are absent). This wouldn't require any actions from developers.

Not sure if this would work with typescript for both designs.

[siriwatknp]

What if, we move the SvgIcon & createSvgIcon inside the icons package and have a default for each them value used (we could use hardcoded values from the Material UI theme). Then, we can allow people to override these things trough the theme, wither by defining some specific tokens in the theme, or via style overrides (whatever we think would work better). There shouldn't be any breaking changes in terms of using it with Material UI as the defaults would be the same as they were before.

I had the same thought about this approach but it would require some time to implement and test.

I think using yarn resolution could be the first workaround that we can add to the documentation page, what do you think?

[mnajdova]

I had the same thought about this approach but it would require some time to implement and test.

I can help with this - create POC and see how it would look like.

I think using yarn resolution could be the first workaround that we can add to the #35377, what do you think?

Honestly, in my opinion this is too complicated for using icons. I could kind of justify this for wanting to use different styling solution, it is a big deal, so if you really want to use styled-components should, go the extra mile, but for using our icons, it seems like we ask too much.

---

Let me create a POC with the alternative next week, and see how big of an effort it would be. I could be missing something :)

[oliviertassinari]

We played a bit with these utils components duplication vs. not duplication problem in #20308. If I recall, we needed to provide icon helpers for material-ui-pickers to create their own.

[mnajdova]

We decided to go with this as a work-around until we have a solution where the icons package depends solely on the system, having the Material Design defaults, and allowing other packages to support overrides trough the theme. I plan to work on this alternative by the end of the month when there isn't much activity :)

[mnajdova]

@siriwatknp should this PR be merged in #35377 so that we have all changes in one PR?

[siriwatknp]

@siriwatknp should this PR be merged in #35377 so that we have all changes in one PR?

Sure, I can do that.