This looks like exactly what I've been itching for in the React styling space. I love the stitches API and I love CSS modules and I really wanted a way to put them together!
However, as a warning to any of you using this documentation for inspiration, I used to really like the "semantic" component layout design advertised in the "full component" example [1], but after spending some time in a code base that does this a lot (one that I helped author, no less), I find it to be an utter disaster. I don't want a bunch of "thin wrapper" CSS components with arbitrary names like Content and Text hiding what the real component is, adding indirections between me and knowing what this component actually is/does! You end up just having to keep track of two (or more, depending on how many indirections someone throws at you) different names for the same component differing in CSS styles only. It's even worse when the name is something like Header which could be anything from an h1 with basic CSS to a full-on header nav for a page.
CSS is not the hard part of writing React. Don't add a million files between you and knowing what a component does, and for the love of God, don't have 100 files named index.tsx unless you want to accelerate the aging process. It's quite frustrating to have 3 tabs open, trying to modify some code that depends on each of them, all of them named index.tsx.
What advantage does this offer over composing using standard CSS classes, and maybe even using something like `classnames` to simplify the conditional logic? Feels like tying your project in quite heavily to a library that might become deprecated.
Looks like it's pretty much just a way to use stitches' typed variant system with CSS modules instead of CSS in JSX. So variants are typed without you manually adding `variant`, `color` etc. boilerplate props any time you want a variation. If it's typed you don't have to dig through CSS files or deal with poor IDE support for CSS module classname resolution, and can instead use the excellent TS support.
As for it maybe being "deprecated" someday... I don't that's a fair criticism, since any library with a small user base is at risk. This one doesn't have much that can rot, it's not like they are doing transpilations, it's just a thin wrapper over React and CSS modules.
However, as a warning to any of you using this documentation for inspiration, I used to really like the "semantic" component layout design advertised in the "full component" example [1], but after spending some time in a code base that does this a lot (one that I helped author, no less), I find it to be an utter disaster. I don't want a bunch of "thin wrapper" CSS components with arbitrary names like Content and Text hiding what the real component is, adding indirections between me and knowing what this component actually is/does! You end up just having to keep track of two (or more, depending on how many indirections someone throws at you) different names for the same component differing in CSS styles only. It's even worse when the name is something like Header which could be anything from an h1 with basic CSS to a full-on header nav for a page.
CSS is not the hard part of writing React. Don't add a million files between you and knowing what a component does, and for the love of God, don't have 100 files named index.tsx unless you want to accelerate the aging process. It's quite frustrating to have 3 tabs open, trying to modify some code that depends on each of them, all of them named index.tsx.
1. https://www.css-components.net/docs/example