Skip to content
This repository has been archived by the owner on Jan 26, 2019. It is now read-only.

CSS Module (again) ? #375

Open
renaudcerrato opened this issue Aug 5, 2018 · 17 comments
Open

CSS Module (again) ? #375

renaudcerrato opened this issue Aug 5, 2018 · 17 comments

Comments

@renaudcerrato
Copy link

I know this have been discussed before in #180, but is there any rationale behind the fact that this typescript fork doesn't (yet) support CSS modules ? This have been merged a long time ago on facebook/create-react-app#2285.

@wmonk
Copy link
Owner

wmonk commented Aug 5, 2018

I'm just in the process of breaking the fork link, at that point i'm happy to get this enabled! #227

@ianschmitz
Copy link
Contributor

This isn't yet in CRA proper. It is part of CRA v2.0 beta.

@gregoryforel
Copy link

@wmonk is it enabled now? I tried a few days ago and could not get it to work.

@raptoria
Copy link

raptoria commented Aug 30, 2018

any update??? :)

@nickserv
Copy link

nickserv commented Sep 1, 2018

In my opinion it would be best to wait for CRA 2 (or publish a prerelease based on CRA 2's prerelease now) to avoid conflicts with CRA in the future.

@r3nya
Copy link
Contributor

r3nya commented Sep 27, 2018

Hi there, it's working.

styles.css:

:local(.class) {} /* for local scope */

.myGlobalClassName {} /* for global scope */

Component.tsx:

// …
import * as styles from './styles.css';

// …
<div className={styles.class} />

Btw, ofc don't forget about declarations for *.css files:

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

@raptoria
Copy link

raptoria commented Oct 2, 2018

@r3nya for the declare module '.css' code, how do you get around the Typescript error 'Invalid module name in augmentation, module '.css' cannot be found.' ? Also, where do you place this declaration?

@r3nya
Copy link
Contributor

r3nya commented Oct 2, 2018

Hm …

@raptoria I created special folder my custom definitions – ./definitions.
And after it I added it into tsconfig.json:

"compilerOptions": {
  // code …
  },
  "filesGlob": [
    "node_modules/**/*.d.ts",
    "definitions/*.d.ts"
  ],
  "exclude": [
   // code…
  ]

And it's working 🤔

@raptoria
Copy link

raptoria commented Oct 2, 2018

@r3nya does cra-ts generate your CSS definitions for you (*.d.ts) or are you doing this yourself? Before I started using cra-ts, I used to setup my own pre-build command that generated all the *.d.ts. Now that I'm using cra-ts, I'm confused as to where/if this is still happening.

@r3nya
Copy link
Contributor

r3nya commented Oct 2, 2018

@raptoria let me create some demo for you…

@r3nya
Copy link
Contributor

r3nya commented Oct 2, 2018

@raptoria please take a look – https://github.com/r3nya/css-modules-and-cra-ts/

@raptoria
Copy link

raptoria commented Oct 2, 2018

thanks a lot for your example, it's extremely helpful. So now when I add a new local css class, I have to do npm run css-types to re-generate the *.css.d.ts

I guess the only thing that's different is the local/global stuff seems to be inverted. It used to be that a class, eg. .header {} would be locally scoped (I can access via styles.header) and to use the global scope I'd do :global(.header) and access using className='header'. Now declaring a class in CSS is automatically global and I have to use the local scope to make it local. Is this specific to cra-ts?

@johnrom
Copy link

johnrom commented Oct 2, 2018

Thanks for creating those demos, it's very useful! In my opinion, I'd be interested to see if one of the "typescript module generator loaders" work, and see if we can wrap css-loader with one when modules are in use. That way it can work out-of-the-box as simply as CRA does, while getting the full benefits of TS.

This is one that worked almost completely for me, but the typescript definitions it spat out were not correct (though I may have configured it incorrectly?): https://www.npmjs.com/package/typings-for-css-modules-loader

If we can't get that to work, maybe my Google-fu isn't working and there is an alternative?

@r3nya
Copy link
Contributor

r3nya commented Oct 2, 2018

@raptoria

Is this specific to cra-ts?

This is the setting for the css-loader from webpack.

Anyway, after #409 we can use typical solutions -> https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-a-css-modules-stylesheet 😉

@jadbox
Copy link

jadbox commented Oct 2, 2018

Coming here just to say that I'd recommend not adding "typed-css-modules-loader" or other css typing system step to be default to react-app-ts project creation. I've tried this route before and found it better to treat CSS imports as just type any. Otherwise, in order to get the type info, you need to parse the CSS file... and there's so many ways that this can break, like due to way CSS preprocessors work. The main issue I hit was I needed to import CSS from a couple 3rd party node_module libraries, but they literally all had some kind of syntax problem that caused typed-css-modules-loader to hard fail the build. I've tested bootstrap 4, material-ui 1.x, and a couple AWS UI components... they all failed being able to be parsed. Just thought I'd relay this info...

@johnrom
Copy link

johnrom commented Oct 2, 2018

@jadbox I think it's definitely important to test using typed module loader wrappers for css-loader , but I'd argue that one can fall back to any by using a plain require() statement, in cases where there is an issue with the types. I think that it would be an odd philosophy for a project whose sole purpose is to provide types for create-react-app, to say "the tooling doesn't work so we should just treat CSS as any", when there is certainly a use case for typed CSS modules.

Typed CSS modules would allow your team to be confident that the classes you're specifying in your component are correct, and that when changing CSS, you can be more certain you're not breaking your component's design. This is a big plus for TS for me.

On the other hand, I think an important part of this issue would be determine if the tooling is there yet, and if not, is there a way this functionality can be provided while providing a fallback when things get out of hand (like require())? And if the webpack build does break in these circumstances with no viable workarounds, then I'd agree that the tooling would first have to improve (but not that we should give up on it!).

@MikelArnaiz
Copy link

@wmonk can you give us any update on this?
#409 looks promising but without css-modules it loses one of the main features of CRAv2

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

10 participants