MUI v5 Emotion Migration: Theme Override Precedence During JSS Coexistence

Answer first

When MUI v4 JSS and MUI v5 Emotion run together, precedence for the same slot is decided by CSS cascade order, not by engine. At equal specificity the rule that appears later in the document <head> wins. MUI v5 theme overrides and the sx prop produce Emotion classes. makeStyles/withStyles produce JSS classes. If Emotion <style> tags are injected after JSS tags, v5 theme overrides and sx will override v4 JSS at equal specificity. If the injection order is reversed, JSS wins.

Confirmed facts

• MUI v5 core uses Emotion for styling. createTheme component overrides and sx generate Emotion classes.
• MUI v4 @mui/styles uses JSS and injects its own <style> tags.
• StyledEngineProvider controls Emotion injection order relative to other engines. This is the documented mechanism for co-existence.
• CssVarsProvider changes value resolution to CSS variables. It does not change cascade precedence between Emotion and JSS.

Likely explanation

Injection order is the practical lever. In a typical incremental migration the intent is for v5 styles to win. That requires Emotion styles to be injected after JSS styles in the DOM. The exact order depends on provider placement and render timing, not on the engine name.

Specificity conflicts can still occur. JSS rules using !important or deeply nested selectors can beat Emotion rules even when Emotion is later in the head. sx tends to generate classes that are placed late in the cascade, which is why it often appears to override both JSS and theme-level overrides.

Recommended conversion sequence for the coexistence window

1. Stabilize injection order. Wrap the app with StyledEngineProvider and verify the DOM order of <style> tags. Keep Emotion after JSS for v5 to win.
2. Move global component overrides into the v5 createTheme object first. Do not duplicate the same overrides in makeStyles. This centralizes the source of truth in the v5 theme.
3. Migrate component-level styling one component at a time: replace makeStyles/withStyles with styled() or sx. Keep the v5 theme override in place until the component is fully migrated, then remove the legacy JSS.
4. Verify each migrated component by inspecting the element in devtools and comparing the winning CSS rule and its source <style> tag.

CssVarsProvider

Enabling CssVarsProvider does not alter the cascade precedence model between JSS and Emotion. It changes how theme values are accessed, via CSS variables, and can reduce runtime specificity churn, but the winner is still determined by DOM order and specificity.

Practical verification

• Open the page and inspect <head>. Confirm Emotion <style data-emotion> tags appear after JSS <style data-jss> tags for the component under test.
• Use devtools Computed styles to see which rule wins for a slot and note the originating <style> tag.
• Test a single component migration in isolation before rolling out broadly.

Assumption: you are using @mui/material v5 with @mui/styles for legacy JSS and StyledEngineProvider is present. If injectFirst is set, the injection order flips and the recommendation changes.

One missing diagnostic that changes the recommendation: is StyledEngineProvider injectFirst currently true or false in your app, and is CssVarsProvider enabled? The desired precedence for v5 over v4 requires Emotion to be injected after JSS, which is the opposite of the injectFirst compatibility setting used when you want v4 to remain dominant.