fix: allow module config while using autoModules (#281)

[katywings]

This includes a fix for #281

Comparison of the options logic (IS / SHOULD columns):

Case		opt autoModules	opt modules	-- will be module?	IS	SHOULD
1	styles.css	false	false
2	...	false	true		yes	yes
3	...	true	false
4	...	true	true		yes	yes
5	...	false	{}		yes	yes
6	...	true	{}		yes
7	styles.module.css	false	false
8	...	false	true		yes	yes
9	...	true	false		yes	yes
10	...	true	true		yes	yes
11	...	false	{}		yes	yes
12	...	true	{}		yes	yes

I hope I didnt make any errors in the table LMAO

• Refs All CSS-files are treated as CSS Modules developit/microbundle#653, Ability to disable CSS minification if needed developit/microbundle#617

[codecov]

Codecov Report

Merging #292 into master will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #292      +/-   ##
==========================================
+ Coverage   92.47%   92.50%   +0.02%     
==========================================
  Files          10       10              
  Lines         319      320       +1     
  Branches      112      113       +1     
==========================================
+ Hits          295      296       +1     
  Misses         23       23              
  Partials        1        1              

Impacted Files	Coverage Δ
src/index.js	98.97% <ø> (ø)
src/postcss-loader.js	92.00% <100.00%> (+0.08%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9489eca...5e5c5b7. Read the comment docs.

[intrnl]

this vs #291 ?

[katywings]

The difference between this two solutions is that #291 requires the consumer to explicitly define autoModules = true if they seek to use autoModules and a custom modules config together. While the fix in this pr doesnt need any consumer changes.

Imho with #291 it would be a little bit weird from a users standpoint:

• autoModules is by default = true
• user later also sets modules: { ... } and expects autoModules to still be true
• but it isnt and so the user then has to set autoModules explicitly to true

[intrnl]

Ah, understood

[marvinhagemeister]

I like this change a lot because it changes the modules flag to be more intended for specifying the naming scheme that is independent of whether autoModules is used or everything should be a module. In my opinion that's the behavior a user would expect without looking at docs 👍

[github-actions]

🎉 This PR is included in version 3.1.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[YIZHUANG]

@katywings So if i wanna use Css modules and global css together i will have to do:

    postcss({
      modules: true,
      extract: true,
    }),

Doesn't work for me though, pure css files still get transformed into css module

[katywings]

@YIZHUANG: Dont set modules: true. If you set modules to true then all files will be interpreted as modules. That was the case before and after this pr, this pr didnt change the behaviour of modules: true because that would have been a breaking change. Please look at the pr description, there is a comparison table with "IS" "SHOULD".

If you think that modules: true should not result in all css files being interpreted as modules, then I recommend you to open a new issue with a change request :).