How do CSS Modules solve global scope conflicts in React?

What's really being asked

This question evaluates whether you understand the mechanics of build-time style scoping and can articulate why CSS Modules are preferable to global CSS in component-based architectures. Interviewers want to see that you know the scoping is achieved by the build tool, not by React itself, and that you can write the idiomatic import and usage pattern.

The full answer

A strong response hits four things in order. First, explain the problem: in standard CSS, all class names are global, so two components defining .button can collide and cause unpredictable overrides. Second, describe the solution: CSS Modules run through a build step that rewrites every local class name into a unique string such as Button_button__3x7a9, effectively namespacing the styles automatically. Third, show the developer experience: you import the module as an object where keys are the original class names and values are the generated hashed names, then apply them via className. Fourth, note the opt-out: you can still write global styles when necessary by using the global keyword or composing classes, but the default is local.

The mistakes people make

Watch out for three red flags. One is saying CSS Modules work by adding JavaScript runtime logic to toggle classes; the scoping is purely build-time. Another is suggesting that you solve global scope by manually using BEM or long descriptive class names; that misses the point because the question asks how CSS Modules solve it automatically. A third is showing an example where you import the CSS file without assigning it to a variable and just use string class names, which is how regular CSS imports work, not CSS Modules.

What usually comes next

An interviewer might push deeper in three directions. They could ask how composition works with the composes keyword to share styles between modules without duplication. They might ask about the difference between CSS Modules and CSS-in-JS libraries like styled-components, specifically regarding runtime cost and server-side rendering behavior. They could also ask how you would configure CSS Modules in a custom webpack or Next.js setup if the convention-based file naming is not used.

A concrete example

Imagine a Button component. You create Button.module.css and write .primary { background: blue; color: white; }. In Button.jsx, you write import styles from './Button.module.css'. Then in the JSX you render a button element with className={styles.primary}. At build time, the bundler transforms .primary into something like Button_primary__2x9f1, and the styles object maps the key primary to that hashed string. If another component also defines .primary in its own module, the generated hash differs, so there is no collision. This keeps the DOM classes unique while letting developers write simple, maintainable class names during development.