typings-for-css-modules-loader 2.0 is now available (fork)

[Obi-Dann]

Hello everyone,

I forked typings-for-css-modules-loader, applied some of the pull requests, made it compatible with css-loader >= 1 and simplified configuration options. You're very welcome to try it and provide any feedback.
https://github.com/TeamSupercell/typings-for-css-modules-loader

There's a list of changes

Changes

• Upgrade all dependencies and ensure the loader works with webpack>=4 and css-loader>=0.28.11
• Remove babel build - make the loader compatible with Node 8+ without additional build steps.
• Change the loader from being a drop-in replacement of css-loader to be used alongside css-loader.
• Remove orderAlphabetically options - the output keys are sorted by default
• Remove namedExport and camelCase options. Generated type definition files now have default export and can both export locals and support dashes in property names out of box. Example:

export interface IMyComponentScss {
  "some-class": string;
  someOtherClass: string;
  "some-class-sayWhat": string;
}

export const locals: IExampleCss;
export default locals;

• Use the built-in webpack logger to report errors. Remove the silent options because it becomes redundant
• Add a new formatter option to allow formatting the generated files with prettier. That should solve the eol issues and apply consistent code style with other files in the code base.

Upgrade guide:

• Update webpack config

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [
          "style-loader",
          {
            loader: "@teamsupercell/typings-for-css-modules-loader",
            options: {
              // pass all the options for `css-loader` to `css-loader`, eg.
-             namedExport: true
            }
          },
+         {
+           loader: "css-loader",
+           options: {
+             namedExport: true
+           }
+         },
        ]
      }
    ]
  }
};

• ensure all the typescript files import styles as default

- import * as styles from './styles.css';
+ import styles from './styles.css';

• add allowSyntheticDefaultImports TypeScript compiler option if there are type errors related to default imports

[CoericK]

Hey @DanNSam thanks for letting us know abut the fork and newer version, Im having issues trying to implement it, can you please take a look at TeamSupercell/typings-for-css-modules-loader#7 (comment)? or TeamSupercell/typings-for-css-modules-loader#8

[weyert]

@DanNSam Thanks for this new version. I am wondering is it possible to still support camelCase for properties with dashes on opt-in basis?

[Obi-Dann]

@weyert unless I am missing something, you should be able to use css-loader localsConvention to achieve that setting it to camelCase or camelCaseOnly depending on your use case. typings-for-css-modules-loader will respect the value set from localsConvention.

[Jad2wizard]

Hello everyone,

I forked typings-for-css-modules-loader, applied some of the pull requests, made it compatible with css-loader >= 1 and simplified configuration options. You're very welcome to try it and provide any feedback.
https://github.com/TeamSupercell/typings-for-css-modules-loader

There's a list of changes

Changes

• Upgrade all dependencies and ensure the loader works with webpack>=4 and css-loader>=0.28.11
• Remove babel build - make the loader compatible with Node 8+ without additional build steps.
• Change the loader from being a drop-in replacement of css-loader to be used alongside css-loader.
• Remove orderAlphabetically options - the output keys are sorted by default
• Remove namedExport and camelCase options. Generated type definition files now have default export and can both export locals and support dashes in property names out of box. Example:

export interface IMyComponentScss {
  "some-class": string;
  someOtherClass: string;
  "some-class-sayWhat": string;
}

export const locals: IExampleCss;
export default locals;

• Use the built-in webpack logger to report errors. Remove the silent options because it becomes redundant
• Add a new formatter option to allow formatting the generated files with prettier. That should solve the eol issues and apply consistent code style with other files in the code base.

Upgrade guide:

• Update webpack config

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [
          "style-loader",
          {
            loader: "@teamsupercell/typings-for-css-modules-loader",
            options: {
              // pass all the options for `css-loader` to `css-loader`, eg.
-             namedExport: true
            }
          },
+         {
+           loader: "css-loader",
+           options: {
+             namedExport: true
+           }
+         },
        ]
      }
    ]
  }
};

• ensure all the typescript files import styles as default

- import * as styles from './styles.css';
+ import styles from './styles.css';

• add allowSyntheticDefaultImports TypeScript compiler option if there are type errors related to default imports

@DanNSam Thank you, could you tell me the version of css-loader you use. I don't find the 'namedExport' property in css-loader options

[Obi-Dann]

@Jad2wizard, sorry, I added namedExport option by mistake. Just merged a PR to remove it from the docs : TeamSupercell/typings-for-css-modules-loader#9

[toniopelo]

Hi @Obi-Dann.

Ended up here because I was searching an option like your formatter option.
I can't switch to your fork because I'm using this package as a dependency of https://github.com/preactjs/preact-cli

Could you file a PR in this repo with your enhancements ?
Then it would benefit a larger community if it gets merged (like every preact-cli user for exemple).

I could do it too, but I prefered to reach out first so you get to be the author 😌
Have a nice day

[Obi-Dann]

Hi @toniopelo,

AFAIK this repo is dead, no PRs get merged or issues resolved - that was the only reason I forked it. I am happy to help with resolving your issue though, perhaps you could raise an issue with preact-cli to switch to the fork? Or if you use yarn, you might be able to replace the original module with the fork via yarn resolutions or something like that

[toniopelo]

Thanks for the answer @Obi-Dann
I understand now, I didn't see the last commit date 🙈

I'll raise an issue on preact-cli.