Lesson Weekend

A natural question at this juncture is: “Okay, if I'm going to start breaking up my styles into multiple files, how do I organize them? What is the proper way to structure my project?” Unfortunately, there are no universal, official-endorsed best practices for this. Different developers, teams, and companies all have their own standards. And sometimes those standards even vary between projects. As Hugo Giraudel states in Sass Guidelines:

Architecting a CSS project is probably one of the most difficult things you will have to do in a project’s life. Keeping the architecture consistent and meaningful is even harder.

At first glance it might be difficult to appreciate the usefulness of Sass while coding such small daily projects. But organization is crucial in the wild, where we're no longer dealing with single static pages, but large applications comprising many moving parts.

7-1 Sass Architecture

One popular and effectively modular way to structure Sass projects is the 7-1 pattern. If your internship or eventual place of employment uses Sass, there's a high chance they use some variation of this type of architecture. So let's make sure you're familiar with it before moving on!


Here's an example sass directory from a project structured in 7-1 architecture, as depicted in the Sass Guidelines article mentioned above. Check it out:

|– abstracts/
|   |– _variables.scss    # Sass Variables
|   |– _mixins.scss       # Sass Mixins
|– vendors/
|   |– _bootstrap.scss    # Bootstrap
|– base/
|   |– _reset.scss        # Reset/normalize
|   |– _typography.scss   # Typography rules
|– layout/
|   |– _navigation.scss   # Navigation
|   |– _grid.scss         # Grid system
|   |– _header.scss       # Header
|   |– _footer.scss       # Footer
|   |– _sidebar.scss      # Sidebar
|   |– _forms.scss        # Forms
|– components/
|   |– _buttons.scss      # Buttons
|   |– _carousel.scss     # Carousel
|   |– _cover.scss        # Cover
|   |– _dropdown.scss     # Dropdown
|– pages/
|   |– _home.scss         # Home specific styles
|   |– _contact.scss      # Contact specific styles
|– themes/
|   |– _theme.scss        # Default theme
|   |– _admin.scss        # Admin theme
 – main.scss              # Main Sass input file

As we can see, everything is in a big sass directory. At the top-level of the directory is a single main.scss file (this is the input file) and seven subdirectories:

  1. abstracts contains no actual styles, just Sass mechanisms that help define styles in other directories (sometimes called "helpers"). This includes things like global variables, functions, and mixins. Each of these categories should be placed in their own appropriately-named partial file, as seen above.

  2. vendors contains any third-party stylesheets a project uses. For instance, if we wanted to use Bootstrap alongside our own custom Sass in a project, we'd download the Bootstrap stylesheet and place it here.

  3. base contains boilerplate used throughout an entire si te. This includes project-wide typography styles, and stylesheets that universally reset or normalize default CSS.

  4. layout contains styles for different aspects of the site's structural layout (think of areas like nav bars, headers, footers, etc.)

  5. components are like "mini" layouts. Styles for small, reusable pieces of the site should reside here (think buttons, forms, profile pictures, etc.)

  6. pages is where page-specific styles reside. For instance, if a project contained several style rules that are only ever used on the "Contact Us" page, they'd live here in a _contact.scss file, as seen above.

  7. themes is used whenever a site has multiple themes. For instance, the example project above includes both admin and default themes. We can therefore assume this example site is styled entirely differently for logged-in admins. Perhaps to better present and accommodate the additional features an Admin has. Some websites also offer a "night mode", where the background of the site is darker with lighter-colored text for easier reading in low-light environments. An option like this would be represented in its own theme file too.

All files from all of these subdirectories are then imported into the main.css input file, in the order listed above, like so:

@import 'abstracts/variables';
@import 'abstracts/mixins';

@import 'vendors/bootstrap';

@import 'base/reset';
@import 'base/typography';

@import 'layout/navigation';
@import 'layout/grid';
@import 'layout/header';
@import 'layout/footer';
@import 'layout/sidebar';
@import 'layout/forms';

@import 'components/buttons';
@import 'components/carousel';
@import 'components/cover';
@import 'components/dropdown';

@import 'pages/home';
@import 'pages/contact';

@import 'themes/theme';
@import 'themes/admin';

But notice there are no styles defined directly in the main.scss input file. In the 7-1 architecture all styles live in an appropriately-named partial, and are simply imported into the input file.

Example Repo

Hugo Giraudel, the same individual who developed this 7-1 architecture, also has a sample boilerplate repository available to explore this structure here: Sass-Boilerplate.

Take a quick stroll through the project. Each directory has its own README that offers further tips and advice. You're also encouraged to 'star' this repo on GitHub for future reference.


One more thing: despite being called "7-1", note that not all of the 7 directories are always required. For instance, some projects may not use third-party stylesheets. Or themes. In this case, we'd just omit those directories from the sass folder entirely. Simple as that!

Moving forward, we'd like you to try organizing your own Sass projects into multiple directories and files, similar to structures seen here. Depending on the size and scope of the project, you may not need all 7 directories. In fact, maybe you'll only need three or four. That's entirely alright; just experiment with the modular paradigm presented by 7-1 architecture.