Webpack loaders are great. With them, you can require() just about any file and the loaders will take care of transpiling into javascript.

CSS Modules are great because you can write CSS for each of your components without worrying about rules from one stepping on the rules of another. The aforementioned webpack loaders (the css-loader in particular) will let you require() your CSS and return a nice map of original class names to generated CSS Module class names so you can do something like:

import styles from './styles.css';
import {render} from 'react-dom';

render(<h1 class={styles.myClass}>Hello, World!</h1>, document.body);

The problem is testing... your testing toolchain (mocha perhaps) doesn't know how to require CSS files. This inevitably leads to a syntax error while node tries to parse the CSS as if it was javascript.

There are several solutions to this problem. The most common solutions either attempt to parse the CSS faithfully or attempt to ignore the CSS require() altogether.

In the first case, you're just complicating things and wasting time. In my automated tests, I don't need to know that myClass is going to become _23_aKvs-b8bW2Vg3fwHozO, so why should I waste the time to parse the CSS to find that out? Further, if there's an error in my CSS, the parsing will fail and cause my component test to fail... is that where the failure belongs? I dunno... maybe, maybe not...

In the second case, all of my class names become empty strings in my automated tests. While it's true that I don't need to know exactly what my class names will become after transpiling, I might want to be able to test that there is some class and I can't do that if just make my CSS require()s return null.

mock-css-modules' solution is somewhere between the former and the latter. mock-css-modules registers a handler for requiring CSS files. When node comes upon a require() for a CSS file, it will run mock-css-modules' handler which will return a Proxy object. This Proxy object will trap getters and return the name of the requested property as a string. So, for example:

import styles from './styles.css';

styles.myClass
=> "myClass"

styles.anotherClass
=> "anotherClass"

etc ...

This gives all of our classes names without the overhead of parsing the actual CSS files. And since code that is using CSS Modules shouldn't be making any assumptions about the names of the generated classes, these values are just as valid as the real ones so they shouldn't cause any issues.

Install with npm:

npm install --save-dev mock-css-modules

Simply require("mock-css-modules") before any CSS files and you'll be rockin'. By default, mock-css-modules will handle require()d .css files. If your project has some other extensions (such as .sass, .scss, etc), you'll need to register handlers for those, too:

var mockCssModules = require("mock-css-modules");

mockCssModules.register(['.sass', '.scss', ...]);

Unfortunately, this means that if you are taking advantage of webpack's resolvers to require() files without extensions, it won't work. You should use extensions for your CSS files.

If you are using mocha to run your tests, you can use mock-css-modules from the command line:

mocha --require mock-css-modules ...

If you need to handle additional extensions, copy the two lines above into a file called test-setup.js, for example, and require the file instead of mock-css-modules directly:

mocha --require test-setup.js ...