Does styled-components SSR rehydration tolerate server and client bundle mismatches during a zero-downtime rollout?

styled-components generates component identifiers at runtime based on evaluation order, so adding or removing a component early in the import graph shifts the identifiers of every component after it. ServerStyleSheet collects rules under those identifiers and emits them into the HTML; the client runtime uses the same identifiers to rehydrate without injecting duplicate style tags.

During a blue-green or canary migration, the server bundle that produces the HTML may not match the client bundle that hydrates it. If the newer client bundle reorders or adds styled components, the runtime identifiers may no longer match those embedded in the server-rendered markup, causing missing styles, duplicated CSS, or a flash of unstyled content.

The babel-plugin-styled-components can assign stable componentId at build time, but it must be enabled with identical settings across all deployed server and client artifacts. Enabling or disabling the plugin between deployments introduces a second mismatch vector unless every artifact is rebuilt together, and exact behavior can vary between styled-components releases.

Can a zero-downtime migration serve SSR HTML from an older styled-components bundle to a newer client bundle without rehydration mismatches? Does enabling babel-plugin-styled-components across all artifacts eliminate the runtime ordering dependency, or introduce new deployment constraints? Which identifier behavior should be assumed when streaming or concurrent rendering paths collect styles at different times than classic string rendering?