feat: CSS Modules support #4852
Conversation
|
is that mean all module stylesheet will be bundle into one css file? |
I noticed that the RFC already mentioned it. Ignore me. |
docs/guides/styling.md
Outdated
|
|
||
| <docs-warning>This feature is unstable and currently only available behind a feature flag. We're confident in the use cases it solves but the API and implementation may change in the future.</docs-warning> | ||
|
|
||
| <docs-warning>Since all CSS Modules styles end up in a single CSS file at the end of the build, we recommend that you only use this styling approach for smaller applications, or sparingly within larger applications. If you're concerned about bundle size, you should probably look at [Tailwind](#tailwind-css) or [Regular Stylesheets](#regular-stylesheets) instead. |
There was a problem hiding this comment.
I'm actually not sure that we need this warning. I think a single module bundle is probably fine for decently large apps since it's easy to cache, and CSS files are rarely a bottleneck before some pretty serious scale. I think we can talk about the tradeoffs without making it look scary.
There was a problem hiding this comment.
It does sound a little scary if someone were evaluating remix and saw this
Not discounting that the warning isn't true. Maybe there are strategies for reducing the bundle size like minifying the CSS.
just noticed out production CSS output isn't compressed in our app 😅
Remix doesn't minify CSS by default?
Not a big deal for our internal tool or web UI, but can be for public facing UIs were download speed matters
There was a problem hiding this comment.
Remix doesn't minify CSS by default?
No, Remix doesn't process CSS by default at all (aside than hashing the filename for effective versioning/caching). This is explained in the same doc.
That said, CSS Modules is opening the door a bit on this bigger question. We should absolutely be able to minify the production build of your CSS Modules bundle IMO.
There was a problem hiding this comment.
I think a single module bundle is probably fine for decently large apps since it's easy to cache
But change any style will break the cache.
There was a problem hiding this comment.
But change any style will break the cache.
As it should! I'm not saying there are no potential perf tradeoffs here, just that we shouldn't overstate them because:
CSS files are rarely a bottleneck before some pretty serious scale
There was a problem hiding this comment.
We should absolutely be able to minify the production build of your CSS Modules bundle IMO.
The generated CSS is already being minified since it's being bundled by esbuild honouring the same minification settings as the JS output.
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
Co-authored-by: Chance Strickland <[email protected]>
|
Hey Mark! Great stuff here, glad to see CSS modules finally coming to Remix. My question here is about third-party libraries support. We import a component library that uses CSS modules via |
|
@xalechez Is the component library open source? I know you'd at least need to add the package to the |
github-actions
bot
added
the
awaiting release
|
🤖 Hello there, We just published version Thanks! |
Closes: #4632
Note that docs will definitely some need more holistic changes once we've removed the feature flag and added more bundling features, but this is PR contains a minimal set of updates to document this change.
I ultimately went with postcss-modules as it's the most commonly used implementation in the wild and we're aiming to support people migrating from other tools. We may use other implementations alongside this in the future if it helps with performance and we can detect that unsupported features aren't being used.
Testing Strategy
I've added a Playwright test suite that checks each CSS Modules feature individually since they have different levels of support with different implementations. I've ensured that all tests are decoupled from the generated class name format since it can differ between CSS Modules implementations.
I've also added some tests to catch potential issues in the future (duplicated hashes, duplicated rules) if we want to migrate to another implementation or change our CSS minification strategy.
Since there was already a deterministic build output test, I've added some CSS Modules files to the fixture to ensure hashes are stable.
Kudos
Big shout out to @chaance for his prior work on #2489 which really helped in this implementation.