Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS Modules not working as document #4376

Closed
Maorey opened this issue Jul 30, 2019 · 3 comments

Comments

@Maorey
Copy link

commented Jul 30, 2019

Version

4.0.0-beta.2

Reproduction link

https://github.com/vuejs/vue-cli/tree/v4.0.0-beta.2

Environment info

Irrelevant

Steps to reproduce

  1. in vue.config.js, set:
css.loaderOptions.css = {
  localIdentName: process.env.NODE_ENV === 'production' 
    ? '[hash:5]'
    : '[folder]-[name]-[local][emoji]',
  camelCase: 'only'
}
  1. yarn run serve

What is expected?

  1. <style> in .vue file is global mode
  2. <style module> in .vue file is local mode
  3. file /\w+\.(?:css|scss|sass|less|styl)/ is global mode
  4. file /\w+\.module\.(?:css|scss|sass|less|styl)/ is local mode
    mode

What is actually happening?

css-loader ValidationError

And try:

css.loaderOptions.css = {
  modules: {
      localIdentName: process.env.NODE_ENV === 'production' 
        ? '[hash:5]'
        : '[folder]-[name]-[local][emoji]',
  },
  localsConvention: 'camelCaseOnly',
}

All css are local mode


Maybe the option css.loaderOptions.css.modules should be rename to avoid conflict with css-loader option.

@sodatea

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

I think this is the natural outcome of the css-loader v3 update.

In the past, it's possible to customize these options without touching the module field. So we can separate the modules options out to css.modules and default it to false, whatever you do on localsIndentName doesn't affect the modules option.

With the css-loader v3 configuration update, it's hard to keep the opt-in semantic of css.modules option if we don't touch the semantic of loaderOptions (they are meant to apply to all nested loaders configs).
I'm still not sure what's the best way out.

@sodatea

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

One possible solution:
If css.loaderOptions.css.modules is not undefined, then the user will be prompt to explicitly set css.modules.
If it's false, then the custom loaderOptions.css.modules only applies to <style module> and .module.css.

@sodatea

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

That feels super unintuitive though.
Maybe css.modules should be renamed to css.enableModulesForAll.

sodatea added a commit to sodatea/vue-cli that referenced this issue Aug 1, 2019

feat!: deprecate `css.modules` in favor of `css.requireModuleExtension`
closes vuejs#4376

Since css-loader v3, cutom css modules configurations are under the
`modules` field. So when user customize these configurations, `modules`
feature is automatically enabled for all css files.
So we must require user's explicit consensus or disagreement on whether
these rules apply to all CSS files or not.

@sodatea sodatea closed this in #4387 Aug 2, 2019

sodatea added a commit that referenced this issue Aug 2, 2019

feat!: deprecate `css.modules` in favor of `css.requireModuleExtensio…
…n` (#4387)

closes #4376

Since css-loader v3, custom CSS Modules configurations are under the
`modules` field. So when a user customizes these configurations, the `modules`
feature is automatically enabled for all css files.
So we must require the user's explicit consensus or disagreement on whether
these rules apply to all CSS files or not.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.