support custom css modules suffix

[sanyuan0704]

Clear and concise description of the problem

At present, Vite can only treat files with the suffix of .module.css as css modules. However, some files do not have this suffix, but they still need to be processed by css modules.

Suggested solution

Support within vite，not a plugin.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

I don't use CSS modules myself, but I personally like how Vite has opinions on things and force users to do things in one way only. Having a new option to specify what considers a CSS module doesn't feel right, and I'd personally prefer it to be a Vite plugin instead, if you need it. (My 2 cents)

[patak-dev]

@sanyuan0704 would you explain why it can't be achieved by a plugin to justify adding it to core?

[hgenru]

I had similar issue with Vite. I think that bundler should be flexible to handle legacy code bases without changes. There is my message' cite from help channel from discord:

Hello comrades!
By default, Vite only enable css-modules for files with the .modules.css suffix. But the problem is that we already have a lot of code where modules are enabled by default for all files.
I've been trying for hours to hack plugins to enable css-modules for all css files, but I've been unsuccessful so far.
I tried to change id to id with suffix .modules.css at the resolveId hook. But because of this, Vite cannot find the files. I tried to write my own plugin that would completely repeat the standard one, but with the changes I needed — but it's very difficult.
Can you tell me how to get the desired result? Thanks in advance.

[hgenru]

If you agree that such functionality is needed, I can make a PR

[bluwy]

I think that bundler should be flexible to handle legacy code bases without changes.

I disagree. Vite is a modern bundler which makes certain tradeoffs and opinions so that it's fast and standard today. For example, source code is ESM only, CJS needs to be prebundled, not shimming nodejs modules, etc. Configuring a modern bundler to support legacy codebases doesn't sound right. I think the legacy codebase should be modernized instead.

IMO new functionality should only be added if there is a real usecase for it, and not for legacy support.

FWIW there's already a PR #6404

[hgenru]

IMO new functionality should only be added if there is a real usecase for it, and not for legacy support.

In our case we do not want to use not moduled css. All global things we place in :global scope. This limitation is deliberately designed to minimize the chance of conflicts and simplify development.

[bluwy]

In that case, I think the limitation or pattern should be enforced in the source code instead of in the bundler. You can rename all of the CSS modules to .module.css, and avoid importing .css. A custom linter could be use to enforce it if needed.

[hgenru]

We can configure the build folder, we can configure the names of the generated classes. But for some reason we can't customize the project structure. It seems to me that this is a little strange. But this is my personal opinion, I'm not a contributor.

I will be very grateful if you tell me how to solve my problem using plugins.

I can also give some context. We have not one project, but many microfrontends. To build microfrontends, we have our own utility with webpack under the hood. But our build utility is very strict in terms of project structure and does not have access to build configuration files for end developers. And I had an idea to port my builder from wepback to Vite to improve DX.

[bluwy]

I will be very grateful if you tell me how to solve my problem using plugins.

I would probably try making a plugin that has:

• resolveId hook to resolve **/*.css ids into **/*.module.css
• load hook to load the **/*.module.css file back from the original **/*.css file from the filesystem
• enforce: "pre" so this happens before Vite's css plugin

Not sure if there's any gotchas but might be worth trying to do so. Otherwise I still think it's best if your project can be refactored to use the .module.css convention.

[userquin]

You have an example here https://github.com/userquin/vite-ssg-swiper/blob/main/vite.config.ts#L29 loading swiper on ssg

[Niputi]

duplicate of #2116 and #2981
user plugin https://github.com/Summer-andy/vite-plugin-transform-css-modules

[jsonz1993]

I wrote a plugin based on bluwy's idea to implement it. https://github.com/jsonz1993/vite-plugin-load-css-module

[lake2]

I wrote a plugin based on bluwy's idea to implement it. https://github.com/jsonz1993/vite-plugin-load-css-module

It still load XX.module.less, and turn out to be 404 eror

[weeeei-bin]

最近有这个需求 写了一个插件 https://github.com/weeeei-bin/vite-plugin-less-2cssmodule