CSS Modules: camelCase keys in styles don’t work locally for kebab-case class names

[paulo-rossy]

Hello team!

After the summer updates, I've encountered an issue with UI rendering locally outside of a Docker container. It is related to this issue: #6418

Initially, I thought the problem was with the Next.js build or the @open-condo/ui package. I recently performed a complete "from-scratch" project rebuild (clearing caches/artifacts, clean dependency install), but it didn't help.

Ultimately, it turned out the issue is connected to CSS Modules and camelCase aliases: the codebase consistently uses styles.someClassName (camelCase), but in the actual styles object on Windows in dev mode, only the original kebab-case keys from the CSS are present. Consequently, classnames(...) forms an empty string.

Environment

• OS: Windows (local development)

Steps to Reproduce

1. On Windows, run the project locally (standard yarn dev / dev mode).
2. Open a page/section that uses a component like MenuItem (example below).
3. Check the DOM in DevTools: the expected CSS-module classes (e.g., MenuItem_*__....) are missing.

Actual Behavior

In the component:

const menuItemClassName = classnames(
  styles.menuItemWrapper,
  {
    [styles.active]: isActive,
    [styles.disabled]: disabled,
  },
  wrapperClassName,
)

Locally, menuItemClassName results in an empty string.

However, the imported styles object is not empty, but its keys look like this:

styles = {
  "menu-item-wrapper": "MenuItem_menu-item-wrapper__wSlC3",
  "menu-item": "MenuItem_menu-item__kzLAG",
  "active": "MenuItem_active__3IVZ3",
  "disabled": "MenuItem_disabled__LMtv6",
  ...
}

This means styles.menuItemWrapper / styles.menuItem become undefined on Windows, because only styles['menu-item-wrapper'] and styles['menu-item'] are available.

Expected BehaviorTo allow using camelCase in the code, CSS Modules are expected to export aliases (e.g., menuItemWrapper for menu-item-wrapper)—as it works in Docker/production.

What I've Already Checked - A complete rebuild/reinstall of dependencies did not help.

• The CSS file is being received by the browser; there are no 404 errors.
• The issue is specifically that styles.<camelCase> doesn't exist => the final className is empty.

Suspected CauseThe project includes a transformation called nextCamelCaseCSSModulesTransform, which should be enabling camelCase exports:

packages/miniapp-utils/src/helpers/webpack.ts:

export function nextCamelCaseCSSModulesTransform (config: Configuration): Configuration {
  ...
  if (loader?.loader?.includes('/css-loader')) {
    loader.options.modules.exportLocalsConvention = 'camelCase'
  }
  ...
}

There might be potential differences in the dev pipeline/paths on Windows.

I can prepare a PR that globally replaces styles.menuItemWrapper -> styles['menu-item-wrapper'] (this solves the problem for me), but it feels like a hack, and I'd prefer not to touch a lot of UI code if the transform can be fixed.

Could you please advise on what might be causing this issue?

[SavelevMatthew]

Hi, thank you for the issue

By default only kebab-cased styles are generated, and all major IDEs are trying to autocomplete in camelCase...

To fix the problem, we're injecting some rule-patching in nextConfig:
https://github.com/open-condo-software/condo/blob/main/packages/miniapp-utils/src/helpers/webpack.ts#L3
https://github.com/open-condo-software/condo/blob/main/apps/condo/next.config.ts#L188

That's might be the clue to the solution... maybe for Windows there's some separate rule...

Unfortunately we're currently developing primarily under MacOS and Linux, so if you can adjust the rules to work on Windows as well - we'll be so excited to merge it to help our community windows developers

[pahaz]

Is the issue resolved?