I'm working with an application that has multiple themes. It has a Material UI theme that MUI v4 uses. It also has an emotion theme that non MUI components use.

I was attempting to migrate to MUI v5. MUI v5 uses emotion under the hood.

I declare the MUI theme higher in the hierarchy than I do emotion.

As far as I can tell, this results in some MUI components receiving the emotion theme (meant for non MUI components) from the context, which breaks their styling (theme.spacing missing for instance).

muiTheme = 1
emotionTheme = 2

<MUIThemeProvider theme={muiTheme}> (from @mui/material/styles)
  <EmotionThemeProvider theme={emotionTheme}> (from @emotion/react)
    <MUIComponent> (from @mui/material)
      // theme => 2
    </MUIComponent>
  </EmotionThemeProvider>
</MUIThemeProvider>

Is there any way to ensure that MUI doesn't consume the wrong theme instance? This would give a lot of flexibility when it comes to migration. In the long term there shouldn't be a need to have two themes, but there are two themes now and doing all the refactoring in one go takes a lot of investment. By looking at MUIs documentation, I understood that this is not a usecase the library supports officially.

Some approaches I've considered that don't seem worthwhile:

• use styled-components for the styled engine to force themes into different contexts
• add more theme provider declarations to ensure that the correct theme is in context for a given part of the application
• naively combine the two themes so that they share the same theme object

Approaches that do seem worth considering, but seem to alter the value proposition by a margin:

• abandon migration to MUI5
• merge MUI4 theme with application theme before migrating to MUI5