[material-ui][Typography] Enforce responsive typography type checking in sx prop

[Sergio16T]

Fixes #42918

Typography Prop Extended to Enforce Typography Breakpoint Types.

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

[mui-bot]

Netlify deploy preview

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

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 556ce79

[Sergio16T]

Reviewed CI build step failure and am working to resolve.

[Sergio16T]

Addressed many of CI failures. Could use an assist with understanding why the test_static is failing with the following prompt: pnpm proptypes` changes committed? I ran pnpm proptypes && pnpm docs:api to generate changes and committed.

[ZeeshanTamboli]

@Sergio16T Thanks for the pull request. I made the necessary changes. We needed to omit the sx prop from other component prop types that extend Typography props. Additionally, we kept the sx propType in Typography as PropTypes.object to avoid a large change, which works well.
Looks good to me. @DiegoAndai @siriwatknp to give a final review.

[Sergio16T]

@ZeeshanTamboli Thank you for the feedback on the PR! Makes sense about omitting the sx prop to reduce the scope of changes. And the same for @typescript-to-proptypes-ignore to disable the proptype generation in favor of PropTypes.object. 🚀

[goodwin64]

I'm curious if we can eventually use custom typography variants if they are re-declared in d.ts files. E.g. will the code above throw an error with this overrides:

export interface CustomTypographyVariants {
  ['H1 title']?: React.CSSProperties;
  ['Body L']?: React.CSSProperties;
}

declare module '@mui/material/styles' {
  interface TypographyVariants extends CustomTypographyVariants {}

  interface TypographyVariantsOptions extends CustomTypographyVariants {}
}

declare module '@mui/material/Typography' {
  interface TypographyPropsVariantOverrides {
    ['H1 title']: true;
    ['Body L']: true;
  }
}

Or in other words, will TS compiler be "okay" with body 1 if we declare it beforehand?

[Sergio16T]

Hello @goodwin64! I believe adding custom typography variants is supported.

I added module override to unit test to confirm this and also locally tested adding the above code block in typography.d.ts

Pushed up unit test update.

[goodwin64]

Awesome news! Thank you so much!

[ZeeshanTamboli]

@Sergio16T Thanks for the test. We handle TypeScript module augmentation tests separately because they apply globally and need isolated testing. For custom Typography variants, there's already a test file. I added this case there instead.

Edit: Even custom breakpoints are supported.

[Sergio16T]

@ZeeshanTamboli, @DiegoAndai, @siriwatknp Commenting to keep this PR active. Awaiting final review.

[ZeeshanTamboli]

@ZeeshanTamboli, @DiegoAndai, @siriwatknp Commenting to keep this PR active. Awaiting final review.

Upon reflection, I believe this is a breaking change. If users extend TypographyProps in their custom components, they must also omit the sx prop if it's defined in their custom component. That would seem like a edge case though. It looks good to me, and I've already requested reviews from others.

[ZeeshanTamboli]

@DiegoAndai @siriwatknp Just a reminder to review this PR.

[DiegoAndai]

Hey @Sergio16T and @goodwin64, I'm sorry for the delay in responding to this PR. It's been an intense couple of months with the v6 release 😅.

Let me know if I understand correctly: the intent of #42918 is for users to be able to restraint the typography type? So it won't accept any other values that are not the variants?

If so, I don't think this should be changed in the component level but rather the SxProps level, as it should work on all components in the same way

What do you think @siriwatknp? I'm not familiar with how the typography sx property is implemented, may I ask you to provide your insight into how it works?

[siriwatknp]

While this fixes the typography but it creates more complexity to the codebase. What's about other fields? I'm pretty sure there will be more requests once this is merged.

The underlying problem is the type of sx prop, not specifically typography. It cannot be enforced to the responsive type because sx prop has to support any CSS selector which is a string.

The best experience I can achieve so far is with autocomplete for the typography but not possible to enforce the responsive keys due to https://github.com/mui/material-ui/blob/master/packages/mui-system/src/styleFunctionSx/styleFunctionSx.d.ts#L64

I put on hold to this PR until we can figure out a better solution for the whole sx type system. cc @Janpot