28

How do you like to organize your large SASS projects?

over 4 years ago from , Senior Interactive Designer / Developer with Hoefler & Co.

So many methodologies here, but I still haven't seen one that really feels like home to me. As a result every project I work on turns into an organizational experiment. Looking for more inspiration here.

39 comments

  • Daryl GinnDaryl Ginn, over 4 years ago (edited over 4 years ago )

    Here's what I used to do:

    • globals
      • reset.sass
      • mixins.sass
      • vars.sass
    • modules
      • page.sass
      • ...
    • components
      • radio.sass
      • checkbox.sass
      • ...
    • posts
      • modules
      • components
      • index.sass
      • show.sass
      • ...
    • app.sass
    • index.sass (imports)

    However, since I started using React, I now keep styles alongside their components, but this used to work pretty well for me.

    8 points
    • Patrick KimPatrick Kim, over 4 years ago (edited over 4 years ago )

      care to explain? Are you doing something like this?

      • components
      • component.js
      • component.scss
      0 points
      • Daryl GinnDaryl Ginn, over 4 years ago (edited over 4 years ago )

        Pretty much exactly that.

        • Checkbox
          • index.scss
          • index.js

        Then I can require the component:

        import Checkbox from './components/Checkbox'

        I also require the SASS file directly from the component using Webpack's SASS loader. Works a charm.

        0 points
  • Evan KnightEvan Knight, over 4 years ago

    Had this question once before too:

    https://news.layervault.com/stories/32730-ask-dn-how-do-you-structure-your-sass-files-in-a-large-project

    http://zurb.com/tavern/questions/how-do-you-structure-your-sass-files

    4 points
  • Tyrale BloomfieldTyrale Bloomfield, over 4 years ago

    This is the structure I use on large projects with 60+ developers. It helps keep things in there proper place, and code is easy to find.

    • Plugins
      • plugin-dir
      • burbon
      • neat
      • bitters
    • Base
      • base-dir
      • typography
      • variables
      • mixins
      • buttons
      • forms
    • Modules
      • module-dir
      • header
      • footer
      • article
      • cards
      • gallery
    • Layouts
      • layout-dir
      • sidebar
      • content
      • lightbox

    All these into their respective -dir file, then those into app.sass.

    4 points
  • Joshua HynesJoshua Hynes, over 4 years ago (edited over 4 years ago )

    @Brandon, we've talked through a few different methodologies on the Stack Overflow Careers Product team. We considered BEM and kicked around Brad Frost's Atomic Design.

    BEM class naming is a bit too verbose for us. We liked the simplicity of the approach though. We also liked the Atomic Design approach, but it felt too heavy-handed for our internal needs right now. Team members were unsure about where to put things.

    In the end our approach is a modified BEM approach. Our folder structure is:

    • base
    • modules
    • views

    Class naming conventions aren't rocket science. We use this approach, which I've seen many others use:

    .sampleElement { ... .-childElement { ... } &._modifyElement { ... } }
    3 points
    • Damian MakkiDamian Makki, over 4 years ago (edited over 4 years ago )

      Instead of appending classes to your HTML, have you thought about writing the SASS like this:

      .sampleElement { ...

      &-childElement { ... } &_modifyElement { ... }

      }

      0 points
      • Joshua HynesJoshua Hynes, over 4 years ago

        I'm not entirely sure you mean. If I have classes like so:

        .sampleElement { ... .-childElement { ... } &._modifyElement { ... } }

        In HTML, we would apply them like so:

        <div class="sampleElement"> <div class="-childElement"> ... </div> </div> <div class="sampleElement _modifyElement"> <div class="-childElement"> ... </div> </div>

        We do it this way so we're not writing out .sampleElement-childElement_modifyElement, which is just an extremely long class name.

        0 points
        • Mathieu MayerMathieu Mayer, over 4 years ago (edited over 4 years ago )

          I'm not sure having extremely long class names is very good indeed. It adds to the overall size of your CSS, in fine.

          However, his suggestion was more to write descendent selectors using their parent class name as a prefix.

          And then target them in your SCSS:

          .foo { &-child { } }

          I've been very satisfied with this method so far as it allow me to nest my SASS files comprehensively and keep my generated CSS as modular and reusable as possible.

          Also, browsers scan class names from right to left... So there must be a gain in speed.

          0 points
          • Per VPer V, over 4 years ago (edited over 4 years ago )

            I also use this approach (LESS) when I write my CSS. The only drawback I find is that it doesn't allow for a good search if you need to search for example .foo-child.

            I've solved this by adding "comments" to each "sub class". Like below. Not the prettiest solution but it works:

            `.block {

            // .block__element &__element {} // .block--modifier &--modifier {}

            }`

            0 points
  • Jean Bertrand, over 4 years ago

    I use the architecture describe here http://sass-guidelin.es/#architecture

    2 points
  • Andrew Richardson, over 4 years ago (edited over 4 years ago )

    We use a system designed around Brad Frost's Pattern Library:

    Basics

    • Reset
    • Mixins
    • Variables

    Atoms

    • Borders
    • Buttons
    • Cards
    • Colors
    • Dropdowns
    • Forms
    • Helpers
    • hr
    • Icons
    • Label
    • Tables
    • Typograpy

    Molecules

    • Flag
    • Gallery
    • Grid
    • Media
    • Well

    Organisms

    • Accordion
    • Breadcrumbs
    • Carousel
    • Modal
    • Nav
    • Pagination
    • Tooltips
    • Wallpaper
    2 points
    • , over 4 years ago

      Oh boy, I'm loving this.

      1 point
      • Andrew Richardson, over 4 years ago

        It works well for my brain :). I like to think of the smallest and simplest elements and work my way up to the larger more complexed ones that require a lot of small elements. That way I can make sure we stay flexible at both a macro and micro level.

        0 points
      • Clark WimberlyClark Wimberly, over 4 years ago

        I'm in the middle of a new mobile build and I'm thinking about going "atomic" with the style/dir/organization and I'm pretty stoked about it.

        0 points
        • , over 4 years ago

          I've spent the last hour collecting articles around Atomic design (which I feel I'm like 2 years behind on) because my initial reading on it kind of gets me really excited.

          0 points
          • Clark WimberlyClark Wimberly, over 4 years ago

            I feel like I've been doing it for years now, but only recently picked up that it had a name. I love designing in small, manageable pieces and then extrapolating up to complex doodads.

            0 points
  • Bobby Grace, over 4 years ago

    Here's what we do at Trello: https://gist.github.com/bobbygrace/9e961e8982f42eb91b80#6-file-structure

    Almost everything is a component. We avoid nesting and mixins and lots of complex preprocessor stuff. We have a BEM-like approach to class names and components, but it’s slightly different. .component.mod-modifer for modifiers. .is-state for state things. .js-action for JavaScript.

    1 point
    • , over 4 years ago

      Is there any reason you use class names instead of data-attributes (regarding .js-action) for targeting elements? I ask because I used to use classes as well but recently switched to data-attributes, just to keep the class list purely style-specific.

      0 points
      • Bobby Grace, over 4 years ago

        It’s just convention. I could see data-attributes working just as well. The important thing is the separation of style and behavior concerns.

        0 points
  • Jim SilvermanJim Silverman, over 4 years ago

    this thread terrifies me.

    1 point
    • Mitch WarrenMitch Warren, over 4 years ago

      How come?

      0 points
    • James Young, over 4 years ago

      Looking through, I actually feel reasonably reassured most people are arriving at a roughly similar happy medium of breaking stuff down into 3 or 4 main folders and on a modular level not going too far (unless you go atomic which feels a little overkill).

      If I were to take on a project from any of the posts here I wouldn't feel too lost in the stylesheets looking at most of the structures which I think is a good thing.

      1 point
  • Leo Succar-FerréLeo Succar-Ferré, over 4 years ago (edited over 4 years ago )

    Similar, just different naming:

    • base

      • _layout
      • _breakpoints
      • _colors
      • _shadows
      • _text
      • _buttons
      • _inputs
      • _icons
      • _variables
    • modules

      • _cards
      • _forms
      • _actions
      • _modals
      • _notifications
      • _comments
    • partials / components

      • _header
      • _account
      • _lobby
      • _gallery
      • _pipeline
      • _feed

    and app.scss imports everything.

    1 point
  • Colm TuiteColm Tuite, over 4 years ago (edited over 4 years ago )

    I wrote a detailed post about this recently, you might take something away from it.

    It's a pretty large app with 40 devs and a couple million active users. Our approach is working great so far.

    1 point
  • Travis VocinoTravis Vocino, over 4 years ago (edited over 4 years ago )
    ┬ ├─┬ sass │ ├── base - base elements in SASS │ ├── colors - where colors are declared │ ├── components - ui components │ ├── fonts - all things fonts │ ├── scripts - Ruby scripted SASS functions │ ├── settings - global sass variables │ ├── utilities - object-oriented css │ ├── vendor - third party CSS libraries │ └── zindex - where z-indexes are declared └─┬ svg - raw svg files ├── [censored] - [censored] ├── [censored] - [censored] └── glyphs - SVGs (font source)
    1 point
    • , over 4 years ago

      I'm so super curious to know what's in your [censored] directories.

      Also, this is the first time I've seen someone else separate their z-index declarations. So helpful.

      3 points
  • Scott OgleScott Ogle, over 4 years ago (edited over 4 years ago )

    I do roughly what most people here are describing, except I like to structure my SASS files to more or less mirror my view templates (i.e., one stylesheet per template).

    So under modules I might have...

    • nav
    • sidebar
    • stage
    • modals
      • confirm dialog
      • other dialog

    etc

    0 points
  • Jake ChapmanJake Chapman, over 4 years ago

    This will start an all out war with being as subjective of a topic.

    The best way to think about it is, smalls bits and pieces.

    I recently just found this, which can help guide you as you figure out your own ways of wanting to structure your stylesheets.

    https://github.com/jasonreece/css-burrito

    0 points
  • James Young, over 4 years ago

    Externals (3rd party styles for anything I use like galleries and stuff) Layout (Higher level layout/page stuff/grid) Modules (Small components) Settings (Variables/Typography etc)

    Anything more seems overkill to be honest.

    0 points
  • Axel CardinaelsAxel Cardinaels, over 4 years ago

    ITCSS by Harry Roberts

    Settings ( basic stuff and very general things like variable declarations for colors etc )

    TOOLS ( mixins, functions etc )

    GENERIC (CSS reset's etc)

    BASE ( Headings base style, links base style, general declaration for body etc)

    OBJECTS (Style you can use multiple times ( like Wrappers etc )

    COMPONENTS ( Specific things, style for a particular part of HTML )

    TRUMPS (useful classes you can use all the time).

    0 points
  • Christopher DunnChristopher Dunn, over 4 years ago

    I used to get caught up in specifying a bunch of directories, but now I keep it simple:

    base/ ------ _variables.scss ------ _functions.scss ------ _mixins.scss ------ _shared.scss ui/ ------ _typography.scss ------ _icons.scss ------ _header.scss ------ _footer.scss ------ _post.scss ...etc vendor/ ------ _normalize.scss

    spaceBase was the inspiration for this.

    0 points
  • Damian MakkiDamian Makki, over 4 years ago

    I think another great question to ask is how are you importing separate SASS files and spitting them out?

    Is everything getting compiled into one style.css and spit out on every page? Do you have one global.css and separate style.css sheets for different pages?

    0 points
  • Thibault MaekelberghThibault Maekelbergh, over 4 years ago (edited over 4 years ago )

    Following simple-sassy-starter:

    ├── _shame.scss ├── screen.scss ├── partials │   ├── _content.scss │   ├── _forms.scss │   ├── _layout.scss │   └── _typography.scss ├── utility │   ├── _mixins.scss │   └── _variables.scss └── vendor └── _reset.scss
    0 points
  • Brian A.Brian A., over 4 years ago (edited over 4 years ago )

    I've been experimenting with this a lot recently and this is what I've settled on (for now):

    Directory Structure:

    SASS Structure 1

    Master Stylsheet:

    SASS Structure 1

    To summarize: master.scss imports all of the _all.scss files from each subdirectory, each of which imports the files from their respective subdirectories. _responsive.scss is on its own and always gets imported at the end to make sure I'm not affecting any core styling.

    0 points