Sass Partials: File Structure and CSS Ownership

What are Sass partials for?

Sass partials are source files, conventionally named with a leading underscore, that another stylesheet loads instead of treating as separate build entries. Organize a small project around one CSS entry file, reusable value modules, and component partials. Use modern Dart Sass modules with explicit dependencies. Keep a record of which files emit CSS, then compile and inspect each intended output in your own environment before shipping.

This is a source-led, five-file reference project, not a framework template. Its purpose is to make three questions answerable: where does a value live, which component owns a selector, and which file produces the stylesheet? The folder names are proposed editorial conventions, not requirements imposed by Sass.

For language fundamentals beyond file organization, use the complete Sass guide. This page concentrates on one small dependency structure rather than a whole-language introduction.

Decide which files own CSS before creating folders

Start with an output inventory. For this example, the intended deliverable is one stylesheet containing a card rule and a notice rule. There is no separate token stylesheet and no standalone component stylesheet.

Use the following ownership table when creating the files:

Sass distinguishes statements that generate CSS from declarations used during compilation. A file containing only the variables below has no selector to contribute. A file containing a style rule does. The underscore alone does not decide that distinction. Sass stylesheet structure

This table is also a useful review boundary. If someone later adds a global reset to the token directory, the change alters the directory's output responsibility. Review that as an architectural change, not merely another line of configuration.

Create one small, complete source tree

Create these five files in a scratch project. The paths are relative to that project's root:

styles/
  app.scss
  tokens/
    _spacing.scss
    _index.scss
  components/
    _card.scss
    _notice.scss

Use lowercase filenames and consistent spelling. Write module URLs with forward slashes, including on Windows. Sass resolves relative module URLs from the file containing the load, and its URL casing matters across platforms. Sass module resolution

First, put the shared values in styles/tokens/_spacing.scss:

$gap: 1rem;
$radius: 0.5rem;

These are illustrative design values, not a prescribed spacing scale. Sass variables are evaluated during compilation; their names are not browser custom properties. Sass variables

Next, give the directory a deliberate interface in styles/tokens/_index.scss:

@forward "spacing";

The index exposes the spacing module's public members to consumers. Forwarding does not itself make those members locally available in the forwarding file; that would require a separate @use. Nor is forwarding inherently CSS-free: a forwarded module's styles are included too. This index emits none because the spacing file contains only values. Sass @forward

Add the complete card component in styles/components/_card.scss:

@use "../tokens";

.card {
  padding: tokens.$gap;
  border-radius: tokens.$radius;
}

Then add styles/components/_notice.scss:

@use "../tokens";

.notice {
  margin-block: tokens.$gap;
  padding-inline: tokens.$gap * 2;
}

Finally, select those components in styles/app.scss:

@use "components/card";
@use "components/notice";

The folder URL loads its index, and each component declares its own dependency. A load in app.scss would not make members automatically available inside the component files. Keep @use declarations before style rules. Sass module loading

All five files are needed for this reference project. Do not paste the five blocks sequentially into one file: the exercise is specifically about file boundaries and relative dependencies.

Trace the dependency direction

Read this project from its output entry toward its values:

app.scss
  -> components/_card.scss
       -> tokens/_index.scss
            -> tokens/_spacing.scss
  -> components/_notice.scss
       -> tokens/_index.scss
            -> tokens/_spacing.scss

The proposed direction is entry → components → tokens. No token file depends on a component. Neither component depends on the application entry. That makes it possible to inspect a component's inputs without navigating the entire application.

Suppose a second component needs the same radius. It can consume the token interface. Suppose it needs the card's selector rules instead. That is a different dependency: decide whether both components should be selected by the entry, rather than making one component load an unrelated component simply to obtain a value.

This is a review heuristic, not a compiler restriction on folder names. A project can choose other boundaries. The important property is that the team can explain each arrow and identify the output it brings.

Compile the entry and inspect the result

Use an already-installed Dart Sass CLI, invoked according to your project's setup. From the scratch project's root, this documented command prints expanded CSS to the terminal rather than naming an output file:

sass --style=expanded --no-source-map styles/app.scss

Here, sass means the executable provided by your environment; a project-local installation may need invocation through its existing package script. Check that environment's compiler version before comparing results.

The official CLI documents single-file compilation, terminal output when the output path is omitted, and expanded formatting. It also documents directory compilation skipping underscore-prefixed partials. That is why app.scss is the intended entry in this tree, rather than four extra component or token outputs. Dart Sass CLI

The expected expanded result for the reference files is:

.card {
  padding: 1rem;
  border-radius: 0.5rem;
}

.notice {
  margin-block: 1rem;
  padding-inline: 2rem;
}

This reference output has not yet been verified with a local compiler. Treat it as a comparison target pending compilation, not as a tested result or production-ready artifact.

The arithmetic is explicit: the notice's horizontal padding is 1rem × 2 = 2rem. The card radius remains 0.5rem. Look for those declarations, the two intended selectors, and the absence of an unexpected global selector from the token files.

Compilation is only one check. It does not establish that these classes are used correctly by HTML, that the visual design meets accessibility needs, or that the actual build tool packages the stylesheet as intended. Test those concerns separately in the application.

Use an output review sheet when splitting an existing file

For an existing stylesheet, preserve a baseline build before moving declarations. Make one structural change at a time and compare the generated result.

An example review sheet for this reference project is:

Do not combine file extraction with a redesigned spacing scale, renamed classes, and a compiler upgrade in one unexamined change. If the output differs, those simultaneous changes make the cause harder to isolate.

For a useful first extraction, select a component whose selectors already form a coherent group. Move its rules, declare its value dependencies, and update the entry. Then inspect the diff. Repeat only after the earlier change is understood.

The Tooling & Workflow hub groups related build topics. The Sass & SCSS hub covers language features that may justify adding another module.

Keep index files and build entries distinct

An index is an interface for consumers; a CSS entry is a build target. In this project, the token index is a partial while app is the build target. Do not create a nonpartial index merely because every directory feels incomplete without one.

Likewise, avoid exposing the whole component directory through the token index. That would turn a consumer's request for spacing values into a request for component styles. Keep the ownership table accurate when choosing what to forward.

A second application entry deserves a second output inventory. Sass's module system is not a website-wide optimizer that removes every repeated selector from independently generated bundles. Check what each build entry produces and what the page actually loads before making a duplication or download-size claim.

For new module organization, use @use and @forward. Sass @import was deprecated in Dart Sass 1.80.0; a file-structure guide should not introduce it as the current default. Sass import deprecation

Frequently asked questions

Does every Sass file need an underscore?

No. In this proposed structure, app.scss is the intended CSS build entry, while the four files it depends on are partials. The distinction records the build plan; it is not a rule that every stylesheet must use the same naming pattern. Check the actual compilation command as well as the filenames when deciding which outputs belong in the project.

Does a partial prevent its styles from appearing in CSS?

No. The card partial in this example owns a .card rule that belongs in app's generated CSS. Its underscore prevents an additional standalone card output during Dart Sass directory compilation; it does not suppress that rule when app loads the component. Keep value-only files separate from files containing selectors if consumers need reusable values without component styles.

Why does each component load the tokens folder?

Both components in the example read values from that folder's public entrypoint. Declaring that dependency in each component makes its inputs visible without first inspecting app.scss. For this proposed architecture, app selects components and components select values; a component should not need to load app merely to obtain a spacing value. Review the direction before adding another dependency.

Should every folder contain an index file?

No. Here, the tokens index is a deliberate public boundary between its consumers and the spacing file. The components folder has no index because app names the two components explicitly. Add an index when it gives consumers a useful stable interface, and record what it exposes and emits. An index that merely hides an unexplained dependency list does not improve ownership.

Will reorganizing Sass files reduce the CSS download?

Not necessarily. Moving the same selectors into smaller source files can leave the generated CSS unchanged. In this example, success means a clearer dependency structure and the intended two rules, not a claimed performance improvement. Compare output size and content using the project's actual build, and test the rendered result before describing a reorganization as an optimization.

Sources

• Sass: stylesheet structure
• Sass: variables
• Sass: @use and module resolution
• Sass: @forward
• Dart Sass: command-line interface
• Sass: import deprecation