File Structure

How to adapt the structure to your framework and scope view-specific styles.

In practice

Here is a typical STACSS project. The files shown are examples — add or remove them based on your needs.

Example structure
styles/
├── utilities/
│   ├── _variables.sass
│   └── _mixins.sass
│
├── base/
│   ├── _reset.sass
│   ├── _fonts.sass
│   └── _themes.sass
│
├── components/
│   ├── _navbar.sass
│   ├── _button.sass
│   ├── _form.sass
│   └── _dropdown.sass
│
├── views/
│   ├── _application.sass
│   ├── _dashboard.sass
│   └── _projects.sass
│
└── helpers/
    ├── _spacing.sass
    └── _flex.sass

Each directory has a specific role and files are loaded in a deliberate order. Refer to the Reference pages for each directory to make sure you place your files in the right location.

  • utilities/ — loaded on demand via @use. These files produce no CSS output on their own and are only included where explicitly imported.
  • base/ — loaded first, before everything else. This is where fonts are declared, CSS custom properties defined, and the global theme established. Everything else depends on what is set here.
  • components/ — loaded after base styles. Components can safely rely on theme variables and the reset being in place.
  • views/ — loaded after components. View styles can override component styles for a specific page without affecting the rest of the app.
  • helpers/ — loaded last, intentionally. Helper classes override all previous styles, which is exactly the point: they allow you to adjust an element's behaviour directly in HTML without writing new CSS.

Entry point

By convention, all files intended to be imported are prefixed with an underscore (_navbar.sass, _reset.sass, etc.). This signals that they should never be compiled directly — only imported by another file.

Your project's main stylesheet loads each directory in order. Note that utilities/ is not included here — it produces no CSS output and is loaded on demand by each file that needs it via @use.

styles.sass
@use 'base'
@use 'components'
@use 'views'
@use 'helpers'

utilities/ is intentionally absent — it produces no CSS output and is loaded on demand by each file that needs it. See the Utilities section.

Index files

It is recommended to add an _index.sass inside each directory. It acts as a single entry point for the folder, making imports cleaner and easier to maintain.

components/_index.sass
@forward 'navbar'
@forward 'button'
@forward 'form'
@forward 'dropdown'

With this pattern, @use 'components' in the entry point automatically loads all forwarded files in the right order.

Adaptability

STACSS provides principles rather than strict rules. The proposed structure should be adapted to the framework you are using.

In a Ruby on Rails project, naming your stylesheet folder views/ feels natural because it mirrors Rails conventions:

Ruby on Rails
views/
├── _application.sass
├── _dashboard.sass
└── _projects.sass

Conversely, in a Next.js project where pages/ is a core concept, that name is more intuitive than views/:

Next.js
pages/
├── _layout.sass
├── _home.sass
└── _dashboard.sass

Always prefer names that match your framework's vocabulary.

STACSS defines conventions and principles, not rigid rules.