CSS Modules with TypeScript: css-modules-typescript-loader

[jednano]

TypeScript users are flying blind when they import a CSS module. For example, if they type styles.foo they have no idea if .foo actually exists in the CSS module without manually checking the file.

This is not a great TypeScript experience.

I propose adding the css-modules-typescript-loader (or something similar) to emit type declarations for CSS modules on the fly.

It could be as simple as this:

  const loaders = [
    require.resolve('style-loader'),
    ...(useTypeScript && cssOptions.modules
      ? require.resolve('css-modules-typescript-loader')
      : []
    ),

What do you think?

[Timer]

I'd love to see a more formal proposal put together for this.

A couple things:

1. This file shouldn't be seen by the user, it's unnecessary diff noise
2. It needs to happen as a preloader on CSS Module files
3. Gain a better understanding of caveats, I believe we opted against this initially.

/cc @brunolemos @ianschmitz

[jednano]

1. It would be excellent if it could be transparently generated, but the file has to be there in order for the TypeScript compiler to understand the structure of the CSS module, so what do you think about adding *.module.d.ts files to the project root's .gitignore to clean up the diffs?
2. Ideally, it would actually happen on file save of the *.module.css file, so maybe this is more of a "Run on Save" command? Otherwise, when you switch from the CSS module to the TypeScript file that imports it, it will still be blind.
3. I'd love to know the reasons for which y'all opted against this functionality.

[Timer]

1. It can be hidden away in node_modules or something, no?
2. Run on save couldn't be safely configured, IMO. Thus the preloader.

[jednano]

1. No. Pretty sure it has to be adjacent to the file in question and it has to have the same file name as the CSS module, so if the CSS module is named foo.module.css the definition file needs to be named foo.d.ts.
2. I agree that would be a tough sell. Not sure what you're envisioning for the preloader, but I'm thinking that probably won't work.

[Timer]

1. We can try both ways.
2. Look at our ESLint loader config, will happen on save while dev server is running and consequently before type checking.

[jednano]

2️⃣ would be a better option, I agree. I don't think most people want to see this generated file.

[mrmckeb]

Could this be implemented as a plugin to TypeScript? It would be great if this happened in-memory, as opposed to needing written files.
https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

[jednano]

@mrmckeb yes like css-module-types. Would a PR be accepted to CRA with this behavior?

[Timer]

Wow, that's rad! The lack of maintenance/use is a little concerning.

[jednano]

@Timer, I totally agree. Be nice to see some tests too. Internally, it looks like it's just a PostCSS plugin, which is a pretty good way of going about it.

[jamsch]

Right now I'm just using the vscode css-modules extension. It works pretty well but won't warn you for invalid styles.

[jednano]

The glory of this feature request is that it would work in any TypeScript-supported editor. @jamsch do you mean it doesn't warn you if you attempt to use a class name that isn't defined in the CSS module file?

[mrmckeb]

@jedmao, if we don't get a response on css-module-types this week, I'll fork the project and add take ownership/responsibility.

• Add tests
• Add support for SCSS