By the way, perhaps this pull request shouldn't close the issues, if it's going to be merged before the above-mentioned changes to css-loader?

Hm, can you provide real use case for this? I am not against this option, I just want to understand the pros and cons of this.

@alexander-akait My own use case is that I have a bunch of React components for tables with different content and layout. However, I still want them to have similar traits. Let's say that it looks similar to the following (untested).

import MyTableBody from './MyTableBody';
import styles from './MyTable.module.css';
export default function MyTable() {
 return (
 <table className={styles.normal}>
 <thead>
 <tr>
 <th className={styles.idHeader}>ID</th>
 <th className={styles.valueHeader}>Value</th>
 <th className={styles.descriptionHeader}>Description</th>
 <th className={styles.deleteHeader} />
 </tr>
 </thead>
 <MyTableBody />
 </table>
 );
}

/* _tables.module.css */
.table {
 table-layout: fixed;
}
.shortNumberWidth {
 width: 150px;
}
.singleButtonWidth {
 width: 65px;
}
.wideTextWidth {
 width: 800px;
}
/* MyTable.module.css */
.normal {
 composes: table from './_tables.module.css';
}
.idHeader {
 composes: shortNumberWidth from './_tables.module.css';
}
.valueHeader {
 composes: shortNumberWidth from './_tables.module.css';
}
.descriptionHeader {
 composes: wideTextWidth from './_tables.module.css';
}
.deleteHeader {
 composes: singleButtonWidth from './_tables.module.css';
}

What I want to accomplish is the following.

1. As I expect to end up with a lot of tables and I want to make use of the power of CSS Modules, I want to split the CSS into individual module files per component.
2. The width of, for example, a column that's meant to hold a short number should be defined in a single place. This means that I can't define it in the individual files but rather in an include file.
3. The JSX should be concerned with the semantic meaning rather than the layout. This means that idHeader is better than shortNumberWidth for a <th> element.
4. I might want to add more styles than just width to a header. This is another reason why idHeader is better than shortNumberWidth for a <th> element, as I avoid having to refactor the JSX to add styling.
5. Furthermore, the JSX shouldn't even have to know that there is an include file. It should be a concern of the CSS, and changes to the CSS hierarchies shouldn't cause changes to which files are included in JSX. Hence, the styles must be imported into MyTable.module.css.

In the example above, I end up with nine classes and each className includes two of them, despite only four of them being needed. In my opinion, the extra classes make the code both bloated and harder to understand. I also believe that when the internal structure of the code directly affects the output, the developer may be pressured into optimizing the code in counter-intuitive ways. Does this make sense?

I will review this in near future