Propose a file structure

[rstacruz]

RSCSS has conventions on how to name your classes and so on, but doesn't really tell you how to organize your files in any way except "one component per file".

In my projects with RSCSS, it's often used with something like ITCSS (inverted triangle CSS), where we have:

@import './variables';
@import './base/*';
@import './components/*';
@import './mixins/*';
@import './helpers/*';

Where:

• variables - yep ($sans: 'source sans pro', sans-serif; $blue: #adf;)
• mixins - yep
• base - things that style bare tags (eg, h1 { font-size: 2.5em })
• components - actual components (eg, .photo-card { ... }) *
• helpers - helper classes (eg, ._nomargin { margin: 0 !important; })

(* The components tree usually gets split up per feature, eg, articles/ profiles/ and so on.)

This all mirrors ITCSS conventions, just with names that I believe are more friendly. (settings → variables, generic → base, trumps → helpers)

I think this should start being an official recommendation of RSCSS. anyone with any thoughts?

[mik01aj]

I use something similar, except I don't have helpers, and my variables, mixins, and base are really minimal. Ah, and I have a (also pretty minimal) reset stylesheet, but I guess that belongs to base in your list.

In my project the main SCSS is /styles/application.scss and it looks like this: (I removed many components for brevity; but you get the idea). I go from generic to specific definitions.

@import "reset";
@import "definitions";
@import "base";

@import "../core/ActivityBox/style";
@import "../core/Avatar/style";
@import "../core/BookCover/style";
@import "../core/Button/style";
@import "../core/CommonIcon/style";
@import "../core/Spinner/style";

@import "../ui/AmazonButton/style";
@import "../ui/BannerSlider/style";
@import "../ui/BlurryBox/style";
@import "../ui/Review/style";
@import "../ui/Video/style";

@import "../dialogs/LoginDialog/style";
@import "../dialogs/RegistrationDialog/style";

@import "../pages/AuthorPage/style";
@import "../pages/BookPage/style";
@import "../pages/SearchPage/style";

@import "../app/Footer/style";
@import "../app/Hamburger/style";
@import "../app/Header/style";
@import "../app/MobileApp/style"; // toplevel container

[rstacruz]

awesome, that looks eerily similar to what we do. sometimes we flatten mixins + vars too for smaller sites.

[darsain]

I personally hate having:

js/components
styl/components
html/components

Seems so redundant, and annoying to navigate in the file tree. Not to mention that you store 3 files for the same component in completely different places in your directory structure. So what I do is just merge those into one root folder:

components/{name}
  - index.js
  - index.styl
  - index.html

The con of this is that names of editor tabs (sublime text) are than all ending in index.{ext}, so it extends them to a longer index.{ext} - components/{name} to help identify the file, but that clutters the tab bar too much. I was thinking of solving this with an editor plugin to rename tabs in this cases to * {name}.{ext} where the * would be some minimal icon to signalize that this is not an actual file name. But that just an unrelated issue regarding editing, not the con of the dir structure specifically.

Other than that, I still use almost exactly the same dir structure as proposed in the OP:

styl/
  variables/
  base/
  mixins/
  helpers/

But I don't really like it. I'd prefer something that would eliminate the need for js, styl, scss folders altogether.

Was thinking of just flattening it to the top, as I can't think of folder name that would collide between js/styl, but dunno how I feel about it yet :)

[eduardomaio]

I like that proposal. I use a similar folder structure but I hate the names trumps and settings. Yours make a lot more sense if you look at the names and think about a usual site structure.

[bas72]

I like that recommendation. I've been using the exact same folders myself, prefer them to the ITCSS naming.

[kminek]

sometimes, at the very end after helpers i put so called external styles for third-party markup & libraries that need adjustments