[BUG] [3.1.2] CSS modules support is broken when optimize.bundle is true

[fgblomqvist]

Bug Report Quick Checklist

• I am on the latest version of Snowpack & all plugins.
• I use package manager npm (Fill in: npm, yarn, pnpm, etc).
• I run Snowpack on OS Mac (Fill in: Windows, Mac, Linux, etc).
• I run Snowpack on Node.js v12+

Describe the bug

Module imports (e.g. import styles from './App.module.css') get turned into something like:

// build/dist/App.module.css
var _default = {};

All of the module files get merged into the single index.css, together with all the non-module CSS. No module-specific actions (like compiling the classnames) get done.

To Reproduce

1. npx create-snowpack-app new-dir --template @snowpack/app-template-react-typescript
2. echo ".foo { width: 100%; }" > src/test.module.scss
3. Add import styles from './test.module.scss' to the App.tsx file.
4. Slap the class on somewhere (i.e. set className={styles.foo} on one of the elements).
5. Set bundle: true in the snowpack config.
6. npm run build
7. Inspect the build output, see the issues mentioned above.

Expected behavior

I'd probably expect the CSS module classes to get compiled and then, perhaps, combined with the other CSS. Finally, the import should be something like var _default = {foo: 'foo_8dj23j9k2'} to link the names.

[makoven]

@fgblomqvist did you find a solution?

[fgblomqvist]

@makoven nope. I also hit #2996 when bundling so I just decided to skip bundling for now (ultimately I don't want to bundle but it would have been nice to be able to switch it on for testing purposes).

[IanVS]

If you're using the default esbuild, maybe it is because of this? evanw/esbuild#20 (comment)

[drwpow]

Thanks for filing. I recently pushed a fix for CSS Modules in v3.3.3 but in more of an SSR context. If you have time, would love to hear if the recent patch is an improvement for you, or not. The change also generates a .module.css.json file with module names as well.

[andreibsk]

@drwpow Could this PR affect SCSS modules loaded with @snowpack/plugin-sass? In my app SCSS modules seem to be missing the mappings in the proxy.js file when using v3.3.3. The results (missing styles) can be seen both when running dev and build. v3.3.2 seems to be fine.
v3.3.3 on the left, v3.3.2 on the right:

[sloonz]

I have the same issue as OP with snowpack 3.3.3

[drwpow]

Thanks for reporting. Will take a look later today. In the meantime please use 3.3.2

[fgblomqvist]

I can confirm that 3.3.3 did indeed break CSS modules (I'm also using sass, like @andreibsk). 😕
It's not just that it's missing the mappings, it's simply not even compiling the CSS classes to begin with.

[drwpow]

@andreibsk @sloonz @fgblomqvist thanks for raising. I’ve made a PR here to fix the core support with Snowpack + CSS Modules: #3186. This should fix the issue, and improve CSS Module output beyond what 3.3.2 and older offered.

However, I am seeing an issue with esbuild—it seems to be stripping the CSS Module names from the final build when { optimize: { bundle: true } } is set. I think that’s a separate issue, and I’ll investigate that after the core fix merges.

[fgblomqvist]

@drwpow Didn't look at the code yet, but the second issue you're talking about sounds like the one I opened this issue for 😄 . Appreciate the fix!

[drwpow]

Sorry—didn’t mean to close the issue. After more investigating, it seems like we are passing just a plain .css file off to esbuild, however esbuild can’t generate CSS Modules (yet). I have a PR up which should fix the original issue in this ticket

Edit: supporting CSS Modules in esbuild will be tricker than additionally anticipated. Currently investigating a workaround, but as @fgblomqvist suggested in #3187 perhaps @snowpack/plugin-webpack may be the quickest solution right now, at least until esbuild supports CSS Modules natively.

[sminnee]

FYI CSS modules are also broken when using @snowpack/plugin-webpack on the following combinations:

It is broken in snowpack@3.8.8 with either of the following combos, and working in snowpack@3.3.2

Combo 1

• @snowpack/plugin-webpack@3.0.0
• webpack@5.51.1

Combo 2

• @snowpack/plugin-webpack@2.3.1
• webpack@4.46.0

I have a suspicion that this might be due to an incomplete fix in #3219.