namedExport not supported

[mgol]

Now that typings-for-css-modules-loader (in this fork) requires most configuration to lie on css-loader, I'm hitting an issue that namedExport is not a supported option in css-loader, see https://github.com/webpack-contrib/css-loader/issues/509. My current setup generates *.d.ts files in a form of:

export const myClass: string;
export const anotherClass: string;
export const yetAnotherClass: string;

Using this fork, the only thing I can achieve is:

export interface IMyStylesScss {
  myClass: string;
  anotherClass: string;
  yetAnotherClass: string;
}

export const locals: IMyStylesScss;
export default locals;

This is quite a big breaking change from what we had before. Is there any way to make it work with existing setup without major changes to the codebase?

[mgol]

I should have mentioned that we have imports in both styles in the codebase:

import styles1 from './styles1.css';
import * as styles2 from './styles2.css';

[Obi-Dann]

Yes, sorry, the namedExport option was added by mistake. Just merged a PR to remove from the docs. #9

[mgol]

Right, that's a significant breaking change, though. Does that mean massive code modifications may be necessary for an update?

[Obi-Dann]

Yes, you're right. All the generated typings will change and imports will need to be changed to use the default export, eg import styles1 from './styles1.css';. The main reasons for the change is to simplify the configuration and avoid limitations of the namedExport.
namedExport was typically set to true in all the environments except when people needed css-loader without style-loader or MiniCssExtractPlugin, eg. get access to locals. Now both locals and default export are supported at the same time.
namedExport didn't support names with dashes that css-loader can output because they were not valid variable names. It's supported now because the module exports an objects with properties instead of a bunch of variables.