[zero] Migrate to use wyw-in-js instead of linaria

[brijeshb42]

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

[mui-bot]

Netlify deploy preview

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

@material-ui/core: parsed: +Infinity% , gzip: +Infinity%
@material-ui/lab: parsed: +Infinity% , gzip: +Infinity%
@material-ui/styles: parsed: +Infinity% , gzip: +Infinity%
@material-ui/private-theming: parsed: +Infinity% , gzip: +Infinity%
@material-ui/system: parsed: +Infinity% , gzip: +Infinity%
@material-ui/unstyled: parsed: +Infinity% , gzip: +Infinity%
@material-ui/utils: parsed: +Infinity% , gzip: +Infinity%
@mui/material-next: parsed: +Infinity% , gzip: +Infinity%
@mui/joy: parsed: +Infinity% , gzip: +Infinity%

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against fd72ee4

[siriwatknp]

I agree with using explicit type, we should mention this in the core meeting to set the consistency.

[oliviertassinari]

But we can't do this with the current version of TypeScript supported https://mui.com/material-ui/getting-started/supported-platforms/#typescript, e.g. #38296.

I believe we need to change this import. I don't even know if #40996 would be enough.

Suggested change

	type PluginOptions as BaseZeroPluginConfig,
	import type { PluginOptions as BaseZeroPluginConfig } from '@mui/zero-unplugin';

[brijeshb42]

I believe we can write this in our source code but it should not end up in the generated d.ts files. This is exactly what is happening right now. If you look at the output, it's like this -

import { PluginOptions } from '@mui/zero-unplugin';

type ZeroPluginConfig = PluginOptions & {
    asyncResolve?: (what: string) => string | null;
};

So there is no type import here.

[siriwatknp]

👍