Jimdo/typings-for-css-modules-loader

Cannot see typing newly generated file (build error)

jurosh opened this issue · 9 comments

jurosh commented

Configuration:

{ test: /\.tsx?$/, loader: 'awesome-typescript-loader' },
{ enforce: 'pre', test: /\.js$/, loader: 'source-map-loader' },
{ test: /\.css$/, use: [ 'style-loader', 'typings-for-css-modules-loader?modules&namedExport&camelCase' ] }

Steps to reproduce:

  1. Start webpack in watch dev server mode
  2. Create new css file like test.css (or add new classifiers)
  3. Include this file in typescript component import * as css from './test.css';

We can watch that test.css.d.ts was generated after we added import and ts loader see this as error.

ERROR in [at-loader] ./src/component.tsx:3:22 
TS2307: Cannot find module './test.css'

After re-running webpack error is gone.

TS-loader needs to wait till *.css.d.ts files are generated - somehow (not sure if it's possible), but it's essential to make this loader totally awesome :)

If there is some hotfix, or I am using configuration incorrectly please give me tips how to apply fix - Thanks.

timse commented

Heja, yeah its a known issue and I haven't found a way to prevent that yet. It sadly is kind of a chicken-egg situation, IIRC.
What may help is to add a general module definition for css as in

declare module '*.css' {
  const css: any;
  export default css;
}

as soon as a typing for a file is found this will get preferred by typescript. However as long as that is not the case this definition is used and the error might go away!

jurosh commented

This definition work for import css from './file.css'; but not for import * as css from 'file.css';. As this second syntax is used for generated typings.

Edit - this declaration will work:

declare module '*.css' {
  interface IClassNames {
    [className: string]: string
  }
  const classNames: IClassNames;
  export = classNames;
}
  • 👍9
sanpoChew commented

@jurosh That didn't work for me for some reason, but after stumbling on this issue microsoft/TypeScript#6615 it turns out that if you're using Typescript 2.0 just doing this works:

declare module '*.scss';

Although it does seem to add ~10 seconds to my build.

  • 👍3
vchrm commented

Hi, any progress on this?

I do not like the declare module ... solution mentioned above since I want/need my application build to crash when there are inconsistencies between stylesheets and their usages in components. (And IMHO you should want that too.)

I guess I'll have to do one extra failing "pre-build" that will generate .scss.d.ts files and a second hot and checked build afterwards. Not very sexy though :-/.

  • 👍10
rhys-vdw commented

My approach for fixing this was to keep the generated files version controlled. Not ideal, and could theoretically permit some errors to get through CI, but it's practical enough for now.

shepmaster commented

I asked a semi-related question on Stack Overflow. It's possible that by both writing the typings to a file and outputting the typings as part of the loader, the initial build might work.

timc13 commented

solving this would make this library a lot more useful!

timc13 commented

unfortunately I had to ditch this library, and use https://github.com/Quramy/typed-css-modules

using the CLI to create typed css modules seems more flexible as I can run it in a prebuild npm script before webpack runs in my build script

  • 👍7
photz commented

I just ran into this when I cloned my project's repo anew and tried to compile my app. Others suggest that just re-running the build-process fixes the problem, but that doesn't work in my case, the type definition files are still missing and the build fails. Has anyone here gotten closer to a solution?

  • 👍1