Folder architecture (7-1 and sane alternatives)

Choosing a folder structure for SCSS before your project outgrows a single styles.scss file. The goal is files you can find, partials that compile in a sensible order, and a layout that still makes sense six months later.

Why structure matters

In the intro series you split styles into partials with leading underscores and pulled them in with @use or @import. That works on small sites. On anything with components, utilities, and third-party overrides, ad-hoc filenames become a guessing game.

Structure is not about being tidy for its own sake. It tells the next developer (often you) where tokens live, where components live, and what is allowed to depend on what.

The 7-1 pattern

The 7-1 architecture (popularised by Hugo Giraudel) splits SCSS into seven ‘abstracts’ folders plus one main entry file. The numbers are a mnemonic, not a law:

• abstracts – variables, functions, mixins (no output CSS on their own)
• vendors – third-party CSS normalised or wrapped
• base – resets, element defaults, typography base
• layout – header, footer, grid shells
• components – buttons, cards, nav blocks
• pages – page-specific overrides
• themes – theme variants if you need them

Your entry file forwards everything in order:

// styles.scss - single compile entry
@use 'abstracts/variables';
@use 'abstracts/functions';
@use 'abstracts/mixins';

@use 'vendors/normalize';

@use 'base/reset';
@use 'base/typography';

@use 'layout/header';
@use 'layout/footer';
@use 'layout/grid';

@use 'components/button';
@use 'components/card';

@use 'pages/home';
@use 'pages/contact';

@use 'themes/default';

Partials and the underscore

Partial files start with _ so Sass knows not to compile them alone. _button.scss is imported as components/button – Sass adds the underscore and extension for you.

Keep one concern per partial where you can. A 800-line _components.scss defeats the point.

When 7-1 is too much

A brochure site with ten pages does not need seven top-level folders. A trimmed structure is fine:

scss/
  _tokens.scss
  _mixins.scss
  _base.scss
  _layout.scss
  components/
    _button.scss
    _card.scss
  pages/
    _home.scss
  main.scss

The rule of thumb: separate tokens/tools (no CSS output), base/layout, and components. Add pages/ when page-specific rules pile up. Add vendors/ when you wrap external CSS.

@use vs @import

Prefer @use and @forward in new projects. @use loads a file once, namespaces members, and makes dependencies explicit. The old @import duplicated globals and made order bugs hard to spot.

// abstracts/_index.scss - barrel file
@forward 'variables';
@forward 'mixins';

// components/_button.scss
@use '../abstracts' as *;

.button {
  padding: $space-sm $space-md;
  border-radius: $radius-md;
}

We go deeper on tokens and maps in the next tutorial. For now, pick a folder list, write it down, and stick to it before file count makes moving painful.

Try it

• Sketch a folder tree for a site with header, footer, three components, and two page-specific layouts.
• Create partials with underscores and a single main.scss entry that @uses them in dependency order.
• Compile and confirm only one CSS file is emitted.