fix: improve esMododule exports

[jantimon]

This PR contains a:

• bugfix
• new feature
• code refactor
• test update
• typo fix
• metadata update

Motivation / Use-Case

With esModule: false the mini-css-extract-plugin generates JS modules like this:

module.exports = {
  foo: "src-styles-foo",
  bar: "src-styles-bar",
};

This allows the following import:

import * as styles from "./styles.css";
import styles from "./styles.css";
import { foo } from "./styles.css";

With esModule: true the mini-css-extract-plugin generates JS modules like this:

export {
  "foo": "src-styles-foo",
  "bar": "src-styles-bar"
};

As there is no default export, the following import will not work:

import styles from "./styles.css"; // Fails

Interestingly the test case es-named-export tests for it:

https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/test/cases/es-named-export/index.js

import css, { aClass, bClass, cClass } from "./style.css";

However when tested manually, the test case fails:

export 'default' (imported as 'css') was not found in './style.css'

This PR adds the defaultExport option to the mini-css-extract-plugin which will allow the user to write the import exactly as in the es-named-exports test case

Breaking Changes

This feature is introduces behind an option.
Therefore this is a non-breaking change.
However changing the named export would probably also be not a breaking change)

need to check behaviour webpack/webpack#18271 (comment)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jantimon / name: Jan Nicklas (1787dab, 023d85c, 9e1c005)
• ✅ login: alexander-akait / name: Alexander Akait (657af90, fe1faa3, ddb84c6)

[alexander-akait]

Let's use namedExport, like we have in css-loader

[jantimon]

@alexander-akait - I added it to the namedExport case - is it okay like this?

[sokra]

Suggested change

	const exportDefaultString = `export default ${JSON.stringify(
	locals
	)}`;
	const exportDefaultString = `export default { ${identifiers
	.map(([id, key]) => `${JSON.stringify(key)}: ${id}`)
	.join(", ")} }`;

That would be a bit more efficient

[jantimon]

done:

--- a/test/cases/es-named-export-as-is/expected/main.js
+++ b/test/cases/es-named-export-as-is/expected/main.js
@@ -17,7 +17,7 @@ var _1 = "Xh041yLR4iCP4RGjge50";
 var _2 = "NMuRsxoDwvW8BhSXhFAY";
 var _3 = "ayWIv09rPsAqE2JznIsI";
 
-/* harmony default export */ const __WEBPACK_DEFAULT_EXPORT__ = ({"a-class":"Xh041yLR4iCP4RGjge50","b__class":"NMuRsxoDwvW8BhSXhFAY","cClass":"ayWIv09rPsAqE2JznIsI"});
+/* harmony default export */ const __WEBPACK_DEFAULT_EXPORT__ = ({ "a-class": _1, "b__class": _2, "cClass": _3 });

could this somehow prevent the minifier from optimizing?

[alexander-akait]

We still need an option for this, otherwise we generate extra content, it is bad for a size

[alexander-akait]

/cc @jantimon

[alexander-akait]

@jantimon Just want to clarify, do you want to use and default and named export together?

[jantimon]

yes for backwards compatibility - right now nextjs allows both

nextjs uses mini-css-extract-plugin but is explicitly setting esModule: false

unfortunately esModule: false has the drawback that it prevents webpacks esmodule optimizations

so my idea was to switch to esModule but also allow named and default exports just like esModule: false

mini-extract-plugin has also a (currently broken) test on master which mixes default and named imports with esModules:

https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/test/cases/es-named-export/index.js

[alexander-akait]

@jantimon I see, we need to verify webpack (experimental.css) work the same (or provide an option to do it) and align with this plugin, I will investigate it tomorrow

[alexander-akait]

Sorry for delay, I done the same for built-in CSS support - webpack/webpack#18271 but want some dicussion with trspack team to align behaviour, then it will be merged I will do the same here

[alexander-akait]

@jantimon I put it under the option, because we still recommend to use only a named export to be better compatibility with future https://web.dev/articles/css-module-scripts

[ahabhgk]

Just for curious, what does "better future compatibility" refer to here? If it's about native CSS modules (https://web.dev/articles/css-module-scripts), it should be distinguishable because of the need for the import-attributes/import-assertions syntax (assert { type: 'css' }).

[jantimon]

@alexander-akait thanks for merging 🎉

Initially I added the default export also behind a feature flag so it's totally fine for me that you brought that back..

However I have one question - should the following css module code cause a warning for better future compatibility?

example.module.css

.default {
  color: red
} 

[alexander-akait]

@jantimon make sense, but I think better to make it in css-loader