modules configuration is very confusing. Could it be simplified?

[dagda1]

I am using version 3.1.8 and had great trouble getting a css file to avoid getting hashed by the module code.

I have a transition.css.

My config was this:

      postcss({
        extract: true,
        modules: true,
        use: ['sass'],
      }),

I had to log this code to work it out even though I read #292 #296

      const autoModules = options.autoModules !== false && options.onlyModules !== true;   // true
      const isAutoModule = autoModules && isModuleFile(_this.id);                          // false
      const supportModules = autoModules ? isAutoModule : options.modules;      // finally false

I ended up eventually with this

      postcss({
        extract: true,
        modules: false,
        autoModules: true,
        use: ['sass'],
      }),

It never occurred to me that modules: false would be the answer or autoModules would not apply to everything.

Should there not just be 1 boolean field and that is it? { modules: boolean }

I don't know the history and apologies if this comes across rude as this is not my intent.

[katywings]

I am the author of said changes and I see it the same as you ^^, having multiple configs which override each other always will result in complexity. My changes fixed issues for some users, but as we now see, resulted in new questions. We really should think about how we can make a module config which is obvious for as many users as possible. Then we can do it as an official breaking change with a major release...

About your config: did you ever try to just do it like this? 😅

postcss({
        extract: true,
        use: ['sass'],
      }),

autoModules, which enables modules for prefixed files, already is enabled by default.

[elpddev]

@dagda1 Thank you. This helped us. Maybe also consider including in the issue name "automodules not working?" so it help others find this solution.

[dagda1]

@elpddev I think rather than change the title of this issue, I think the API could be more obvious. What do we think would make sense as an API?

[elpddev]

@dagda1 I came to this issue because I fell on case that every css was considered css module, not only module.css.

Regarding the API, maybe those varitaions could make it more clear?

1. cssModule: boolean (true/false) cssModulePattern: regex or
2. cssModule: boolean/regex // true, false, pattern