Ask DN: How do you structure your SASS files in a large project?

over 8 years ago from , Design @Google

I’m working with about 10,000 lines of (desktop and mobile web) SCSS/CSS, which I’m aiming to minify and restructure. How do you structure your SASS for scalable projects? And do you use SMACCS, OOCSS, or BEM?

I also asked this question on Tavern:, but I


  • Jonathan SuhJonathan Suh, over 8 years ago (edited over 8 years ago )

    I use a combination of SMACSS, OOCSS and BEM.

    Here's a screenshot of how I've organized the Sass in one of my most recent projects:

    I hope this gives you a bit of context. I also now include a z-index as well in the core to manage all of my z-index values. I consider modules any elements that could be considered reusable throughout your project.

    BEM can become verbose so I try to extend classes when possible, even using silent classes. In my naming convention, I personally don't use underscores. Hyphens as separators and double-hyphens as a modifier.

    If you have any specific questions feel free to ask, and I'd be more than happy to answer them to the best of my knowledge and ability.

    9 points
    • Evan Knight, over 8 years ago (edited over 8 years ago )

      Nice! Thanks for sharing.

      1.) Interesting that you have folders within pages, and it looks like a .scss file for each page. Do you find it easier or harder to manage than having a header.scss, and body.scss?

      2.) Since you have files for individual pages, do you use unique class names and format them using something like @include grid_6 similar to this? Or do you use bootstrap style

      in your markup?
      1 point
      • Jonathan SuhJonathan Suh, over 8 years ago (edited over 8 years ago )

        1) Every page does have its own .scss file, but many times it's modifying a module. For example, there's .hero but in the home.scss file, I'll have .hero--home and have it modify the background-image. Occasionally it'll have it's own page-specific element, which that'll go there as well.

        I don't like having page-specific modifying classes in a global module. I find that it's easier to have a separate file for page-specific stuff, even if it only has a few lines.

        I don't think it's harder. It's just a few more steps to create and import the file when you have a new page, but I find the separation easier to manage in the long-run.

        2) Reiterating some of my first answer, for individual pages most of the time it's modifying classes, whether I'm extending an existing class or with BEM doing a --modifier.

        I used to use Foundation, but I've migrated to using Neat http://neat.bourbon.io/ nowadays. More often than not I find myself creating my own breakpoints. I do not use Foundation/Bootstrap style markup (if you're asking if I do things like class="large-columns-6 medium-columns-5 small-columns-4"). I try to keep much of that logic in my CSS + media queries.

        0 points
    • Andrew ColcloughAndrew Colclough, over 8 years ago (edited over 8 years ago )

      Nice Jonathan. Your answer is almost mine exactly: smacssStructure

      I have greatly simplified the structure over time. Nearly everything is a module that isn't part a Base element. No more layouts, pages, or even a states folder.

      I have a more detailed write-up on my combo strategy, naming patterns, states, etc - if anybody cares Objects in Space.

      Cheers. -adc

      1 point
  • Darth BaneDarth Bane, over 8 years ago

    I will never understand the micro-structuring that some people use. I use the following:

    • _animations.sass
    • _defaults.sass
    • _mixins.sass
    • _normalize.sass
    • _variables
    • main.sass

    ...and then a folder called 'page', in which I have stuff like:

    • page/inbox.sass
    • page/settings.sass

    ...etc. I see no reason as to why it should be more fragmented than this.

    3 points
    • Matt SoriaMatt Soria, over 8 years ago

      It's just preference. I just started co-working with a developer who has the same preference as you — putting almost everything into one big main.sass file or whatever, and I like to break mine up into much smaller pieces — into modules, and a file for each page, etc., and what I realized when talking to him is that he would prefer one long file with almost everything in it, scrolling to different modules and pages that are separated by comments over switching to a different file, whereas I would much prefer many short files that don't require much scrolling or searching, and find it easier to see where things are located if they have their own file, which is name accordingly.

      He prefers to search/scroll, I prefer to open up a new file. It's just preference.

      I'll tell you one thing though, in terms of passing code along and picking up on a project I think it'd be much more clear to a developer where things are located if they are broken up into smaller pieces. For example, looking at your sample file structure, if I came in to do some work on the forms I'd say "Hmmm...which file are the form styles in....let me search..." — but if they were in _forms.sass I'd know immediately. No searching! Make sense?

      1 point
      • Darth BaneDarth Bane, over 8 years ago

        Yeah I mean I get normal structuring, but some of the examples I see are borderline crazy in terms of micro-ordering.

        It reminds me of when I was a musician and there were musicians who spent all their time putting pedal boards together, soldering awesome cables and putting it all in fancy flight cases....and then there were musicians who actually played music. ;)

        In terms of your example, I wouldn't mind adding a _forms.sass file to make it easier. But adding a forms file inside core/pages/login/mobile/whatever to target a specific mobile login just seems long winded to me.

        0 points
        • Matt SoriaMatt Soria, over 8 years ago

          Oh, gotya. Yeah, I haven't really found a need to ever split folders into sub-folders, and I've worked on a project that had quite a large code-base, though again, to each their own — I'm sure there are situations in which it makes sense, though I'd share your hesitance when it comes to getting that minute with it.

          0 points
  • Sacha GreifSacha Greif, over 8 years ago

    I separate my files into three categories:

    • Includes: for mixins, variables, etc.
    • Specific: for page-specific styles.
    • Global: everything else.

    I'm considering adding a fourth category for layout, but it can be hard to keep that separate from other styles sometimes…

    1 point
  • Francesco BonomiFrancesco Bonomi, over 8 years ago

    Asked the same thing some time ago, take a look at the answers :)

    1 point
  • Jeff HeatonJeff Heaton, over 8 years ago

    I use CSS Burrito, a structure and set of tools developed by one of my coworkers. It's good stuff: https://github.com/jasonreece/css-burrito

    0 points
  • Jack Ketcham, over 8 years ago

    I like the commentary on how Medium structures their LESS files; breaking it down by modules first, and then by pages as it becomes necessary.

    Definitely read this if you haven't already: https://medium.com/@fat/mediums-css-is-actually-pretty-fucking-good-b8e2a6c78b06

    0 points
  • Ivan DrinchevIvan Drinchev, over 8 years ago

    I'm using a convention that I follow for my views, scripts and stylesheets. Basically it looks like this :


    SCSS :

    • components is a folder where I put logically separated parts of the layout ( think of header, footer, navigation, article, modal, etc. ). Inside I can also have different similar components, like in this case I use filters for all side menu filters that can narrow a search of products ( that's actually a e-commerce website ) - prices, brands, etc .
    • debug is a folder where I put styles for testing the layout and elements ( I have a grid inside and borders for some elements to intersect for pixel perfection )
    • layouts is a folder which have bases of different pages. In this project I have only one _base.scss file inside, which is similar to HTML5 boilerplate that you can find around the web.
    • lib is a folder which have only mixins ( files that don't render anything in the compiled CSS ) - think of em-calc and other tools
    • pages is the only folder that have files that doesn't start with "", so they are compiled to .css and contain a lot of includes. In this project here I store index.scss and shop.scss, both of them include files from components, ui, lib, layouts and if something is included in the two files like **header.scss, then I put it in the **layouts/base.scss
    • ui is a folder where I keep UI html elements styles. Think of select, input type['text'], button, textarea, etc.
    • vendor is a folder where I keep CSS that is not written by me : jquery-ui
    • _configuration.scss is included in the base layout ( which means every page ) and consists of colors and fonts configuration.

    Keep in mind that my CoffeeScript ( compiled to javascript ) is also using the same convention

    0 points
  • Evan Knight, over 8 years ago

    for the mods, you can delete ":, but I" :)

    0 points