Repository navigation
[Request]:Consolidate "Styling your components" guides into an external resources directory #1593
Description
What is this request related to?
Request
📋 Suggested
https://docs.solidjs.com/guides/styling-components/css-modules
📋 General description or bullet points
Context
Following up on the discussion in PR #1583, it's clear that the docs team is currently stretched thin. Maintaining dedicated setup guides for external CSS frameworks (Tailwind, UnoCSS, Macaron, LESS, etc.) introduces a continuous maintenance burden, especially as those external APIs evolve.
The Problem
Currently, the "Styling your components" section hosts extensive configuration guides for various tools. Keeping these up-to-date pulls focus away from documenting core SolidJS features. Additionally, it creates friction when trying to add new tools (like Panda CSS) because adding them means adding more maintenance weight to the solid-docs team.
The Proposal
Instead of hosting full installation and configuration guides for external styling libraries, I propose we consolidate this section into a single "Styling Ecosystem" or "External Styling Resources" page.
This page would:
Briefly explain the different approaches to styling in Solid (e.g., CSS Modules, CSS-in-JS, Utility-first).
Provide a directory listing of popular community-adopted tools (Tailwind, Panda CSS, UnoCSS, Macaron, etc.).
Link directly to each tool's official SolidJS installation guide on their respective documentation sites.
Benefits
- Reduces Maintenance Burden: The Solid team no longer has to maintain and test configuration steps for third-party styling tools.
- Always Up-to-Date: Users are routed to the source of truth, ensuring they always get the latest configuration steps directly from the framework authors.
- Easier Ecosystem Expansion: Adding a new tool to the docs becomes a simple one-line link addition rather than a multi-page guide review.
🖥️ Reproduction of code samples in StackBlitz
N/A
Activity
LadyBluenotes commentedon Jul 25, 2026
I think that's a good idea. If you'd like to take it upon yourself to do, please feel free!
kalisaNkevin commentedon Jul 25, 2026
Hi @amirhhashemi any suggestions on this ?
amirhhashemi commentedon Jul 26, 2026
@kalisaNkevin I like this a lot better.
I think we shouldn't get into the business of comparing frameworks or approaches. Users most likely already know what they want to use for styling. Just broadly categorizing them into three main groups ("CSS-in-JS," "Utility-first," and "CSS Preprocessors") should be enough.
It's also worth mentioning that Vite has built-in support for
sass,less, andstylus. I think we should keep those guides in our docs to avoid misleading users into thinking they need additional setup. These pre-processors require minimal configuration, and maintaining them is manageable.kalisaNkevin commentedon Jul 26, 2026
Fully agree @amirhhashemi.
The three buckets (CSS-in-JS, Utility-first, CSS Preprocessors) are the right call no editorializing, and people usually arrive knowing what they want. And keeping
sass/less/stylus+ CSS Modules in-docs makes sense exactly because Vite handles them natively; pulling them would just make users think extra setup is needed. Those are stable and cheap to maintain.The part I like most about this model is that it fixes the original maintenance problem: the moment a tool needs framework-specific, evolving setup, we link to its official Solid guide instead of owning it. That's what makes the section future-proof a new tool is one line, not a new page to test.
Panda CSS is the clearest example of why that matters: it's a build-time CSS-in-JS / styled-system tool we don't cover today, and under the directory it's just a link with zero upkeep on our side. So the model doesn't just reduce our current burden it lets the section keep pace with the ecosystem without adding any.