wmr: Typescript error for css module imports

@Paratron try adding this to your tsconfig.json:

"files": ["./node_modules/wmr/types.d.ts"]

I just wanted to note that I created a new WMR project with npm init wmp whatever a couple of minutes ago and I have the exact same error in the provided example code:

This is a different issue (or feature). preact is installed locally if you run npm run build but not by default. preact-iso lists preact as a dev-dependency which is why it’s not installed when you npm install on a wmr template project.

Yeah, we noticed that yesterday and this was fixed with #256

I was going to open a PR but it seems the code on master will fix this issue.

I think the issue @ivancuric and I are seeing is related with the order ambient modules are declared. This is the order I’m getting with wmr@1.0.0 :

// types.d.ts
declare module '*.css' { const url: string; export default url; }
declare module '*.scss' { const url: string; export default url; }
declare module '*.sass' { const url: string; export default url; }
declare module '*.styl' { const url: string; export default url; }

/** Maps authored classNames to their CSS Modules -suffixed generated classNames. */
interface Mapping { [key: string]: string; }
declare module '*.module.css' { const mapping: Mapping; export default mapping; }
declare module '*.module.scss' { const mapping: Mapping; export default mapping; }
declare module '*.module.sass' { const mapping: Mapping; export default mapping; }
declare module '*.module.styl' { const mapping: Mapping; export default mapping; }

But on master the order is correct. (which is a bummer, I was eager to make a splash with an easy fix PR )

@Paratron Unfortunately that’s an issue with the way JetBrains handles types. I raised the issue a few months back, but they have no interest in fixing it. I ended up switching away from their products shortly after. You can add a dummy import 'wmr'; to say your index.js to remove the error.

Edit: I shouldn’t say they have no interest in fixing it. They argue that types from a package that is not used should not be used. As WMR is a build tool, it is not directly imported, ergo, JB says the types it provides shouldn’t be used. I’m not entirely sure if I agree or not, as I can see the logic either way, but that’s their position and it’s at odds with what we currently do here.

Ah thanks for clarifying that @Marabyte, I hadn’t realized it was because of the peerDependencies thing. preact-iso is correct in that regard, we just needed to have create-wmr do the right thing as @rschristian mentioned.

We’ll get a release out today that sorts these things out.

Ok, I had "typescript.disableAutomaticTypeAcquisition": true, enabled in VScode for some reason. Removed it.

Now two projects using create-wmr are reporting different errors. A newly created one can’t seem to get typings for preact/hooks and there are errors when accessing CSS modules:

<section class={styles.home}>

Property 'home' does not exist on type 'string'.ts(2339)

Could be a VScode / TS quirk.

There is a tsconfig.json but it was generated using create-wmr.

{
	"compileOnSave": false,
	"compilerOptions": {
		"jsx": "preserve",
		"allowJs": true,
		"checkJs": true,
		// "strict": true,
		"noEmit": true,
		"moduleResolution": "node",
		"target": "ESNext",
		"module": "esnext",
		"resolveJsonModule": true,
		"allowSyntheticDefaultImports": true,
		"downlevelIteration": true
	},
	"typeAcquisition": {
		"enable": true
	}
}

What’s interesting is that I don’t seem to have any typing available. Everything is either inferred return types or any.

Eg About is inferred as:

const About: ({ query }: {
    query: any;
}) => any

The only thing that seems to be typed is useState from preact/hooks:

(alias) function useState<S>(initialState: S | (() => S)): [S, StateUpdater<S>]
import useState

// Returns a stateful value, and a function to update it.
// @param initialState — The initial value (or a function that returns the initial value)

I’m using VScode 1.52 if it helps.