Generated typings not compatible with project

[aaronbeall]

I am using this loader setup for TypeScript and PostCSS with Webpack 1.13.1:

{
  test: /\.tsx?$/,
  loader: 'ts',
  exclude: /node_modules/
},
{
  test: /\.css$/,
  loader: 'style!typings-for-css-modules?modules&camelCase!postcss',
  //loader: 'style!css!postcss'
}

(The commented out css loader is the previous setup which works without CSS modules.)

When I import a .css file using import {locals as styles} from "./example.css" as the generated typings indicate, I get nothing at runtime. If I use import * as styles from "./example.css" I see all the class names at runtime, but still no locals, and TypeScript flags errors for all references, such as styles.myClassName.

[timse]

can you paste the generated typings here?

[aaronbeall]

Example:

export interface IEstimateProjectRowCss {
  'estimate-button': string;
  'estimateButton': string;
  'hovered': string;
  'selected': string;
  'bg': string;
}

export const locals: IEstimateProjectRowCss;

The thing I don't understand about this output is that locals is not a thing I see in the generated JS module at all.

The generated typings for namedExport seems correct, but some of our class names are reserved words so we cannot use this without some refactoring.

[aaronbeall]

I think it's because I'm using style-loader. My whole loader is:

{
  test: /\.css$/,
  loader: 'style!typings-for-css-modules?modules&camelCase!postcss',
}

If I understand the comment in the documentation about exports being extracted out of locals when used with style-loader then it explains the mis-match.

But does this mean there's no way to use non-namedExport typings with style-loader?

[timse]

need to look into this when i find the time!

[scamden]

i see the same thing without using style-loader or postcss just fyi

my config with postcss commented out for testing:

        loader: 'typings-for-css-modules-loader',
        options: {
          namedExport: false,
          camelCase: true,
          sourceMap: true,
          modules: true,
          importLoaders: 1,
          localIdentName: '[name]__[local]___[hash:base64:5]'
        }
      },
      // {
      //   loader: 'postcss-loader',
      //   options: {
      //     plugins: (loader) => [
      //       autoprefixer(),
      //     ],
      //     sourceMap: true
      //   }
      // },
      'resolve-url-loader?sourceMap',
      'sass-loader?sourceMap'
    ]

passing the above to extract text plugin

[timse]

any idea how to fix that @scamden ?

[scamden]

sorry for the delay. many build issues to figure out at the moment :P

did you happen to see my comment on 81ff68c?

i'm not too sure but i think this commit is just wrong? css-modules seems to export not on a locals object at all but just at the root of the module. let me know if i'm missing something about how this all works but maybe the fix is to just revert this commit and go back to exporting as default?

[aaronbeall]

@scamden Actually css-loader (and by extension typings-for-css-modules-loader) exports a locals object, but style-loader and ExtractTextPlugin both move all the keys of locals to be direct named exports. So the correct type defs really depends on whether or not style-loader or ExtractTextPlugin is in play. The namedExport option only toggles how typings-for-css-modules-loader exports in the type defs, not how the css module is actually exported -- that, again, depends on what else in play. This was my initial confusion that led me to enter this issue, but AFAIK the type defs are correct, it's just confusing to figure out what your type defs should actually be. I haven't really found an explanation on what or why the locals object is there and melts away with style-loader or ExtractTextPlugin, but documentation was never quite Webpack's strong point. :)

[scamden]

@aaronbeall that makes sense. unfortunately it still leads to a bug right? because ultimately ts won't let me get the css class off the default object and if I use the locals object as the types suggest it fails at runtime (since they are not actually there after extract text loader runs). if you determined that this was ultimately correct how did you remedy? @timse is there a way to perhaps add a flag for style / extract text mode?

[aaronbeall]

@scamden That's what namedExport does

[scamden]

well unfortunately it's not all it does haha. it also causes classnames using reserved js keywords to fail. i would love to use namedExports, but it's not compatible with twitter bootstrap for example which uses the classname "in" for modal animations. would be awesome to have an option not to use named export but still export the big map object as default for loaders that expose it that way

[aaronbeall]

Yeah, you're right. I guess there's just no way to use named exports with reserved words. It is possible to export top level reserved word keys, though, using export = syntax:

interface IFooCss { }
declare const styles: IFooCss;
export = styles;

That could be a new option?

As for the default export, that seems to only work if you use module: "es6" in tsconfig, whereas if you use commonjs for example you get no default imports. So again the right type defs depend on your configuration. This could be yet another option, now we have namedExport | exportLocals | exportInterface | defaultExport, which are mostly mutually exclusive. Or you could just refactor away your reserved words and use namedExport. :)