A partial is a Sass source file intended to be loaded by another stylesheet rather than compiled as an independent entry point. Partial filenames conventionally begin with an underscore, such as _variables.scss or _buttons.scss.

A project may separate tokens, functions, mixins, base styles, layouts, components, and utilities into focused files. A small number of well-defined entry points can then compose the required modules.

Avoid creating a file for every trivial declaration. File boundaries should communicate architectural responsibility and make ownership clear.

A typical structure might look like this:

src/scss/
  abstracts/
    _tokens.scss
    _functions.scss
    _mixins.scss
  base/
    _reset.scss
    _typography.scss
  components/
    _buttons.scss
    _cards.scss
  layout/
    _header.scss
    _grid.scss
  main.scss

The underscore is a naming convention associated with Sass partials. A module is loaded through Sass's module resolution rules, and the importing file's path is resolved relative to the configured load paths.

The @use rule loads a Sass module and exposes its public members through a namespace. This makes dependencies explicit and helps prevent accidental name collisions.

For example, @use "abstracts/tokens"; loads a module whose variables can be accessed through the tokens namespace. The consuming file can then reference tokens.$brand-color.

Use as to select an alias or as * to remove the namespace. Although as * can shorten names, it can also reintroduce naming collisions and hide dependencies. Explicit namespaces are generally easier to maintain in large projects.

Sass modules are loaded once within the module system, so repeated references to the same module do not behave like repeated textual concatenation of the source file.

The @forward rule re-exports members from another Sass module. It allows a directory or package to provide a centralized entry point instead of requiring every consumer to know the location of each internal file.

For example, an abstracts directory can forward its tokens, functions, and mixins through a single _index.scss file. Consumers then load the index module and access the exposed API through one namespace.

The show and hide options can control which members are re-exported. The as option can rename forwarded members. These capabilities help establish a deliberate public API for a shared design system.

Forwarding is especially useful for Sass libraries, component systems, and multi-package repositories. Internal implementation files can change while consumers continue using the public entry point.

Sass modules can expose configurable variables by declaring defaults with !default. Consumers can configure those variables when loading a module with @use and a with clause.

This approach is useful for white-label applications, component libraries, and design systems that allow a consumer to override approved brand tokens.

Module configuration must occur when the module is first loaded. A module cannot be independently configured multiple times with conflicting configurations within the same compilation context.

Keep configurable values focused on stable customization points. Exposing every internal variable makes the module's public API difficult to maintain.