Skip to content
This repository has been archived by the owner on Oct 30, 2020. It is now read-only.

Cannot see typing newly generated file (build error) #33

Open
jurosh opened this issue May 17, 2017 · 9 comments
Open

Cannot see typing newly generated file (build error) #33

jurosh opened this issue May 17, 2017 · 9 comments

Comments

@jurosh
Copy link

jurosh commented May 17, 2017

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
Copy link
Contributor

timse commented May 21, 2017

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
Copy link
Author

jurosh commented May 23, 2017

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;
}

@sanpoChew
Copy link

@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.

@vchrm
Copy link

vchrm commented Sep 11, 2017

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 :-/.

@rhys-vdw
Copy link

rhys-vdw commented Dec 7, 2017

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
Copy link

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
Copy link

timc13 commented Jan 30, 2018

solving this would make this library a lot more useful!

@timc13
Copy link

timc13 commented Jan 30, 2018

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

@photz
Copy link

photz commented Sep 26, 2018

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants