Sass imports have the same syntax as CSS imports, except that they allow multiple imports to be separated by commas rather than requiring each one to have its own @import. Also, in the indented syntax, imported URLs aren’t required to have quotes.

// foundation/_code.scss
code {
  padding: .25em;
  line-height: 0;
}

// foundation/_lists.scss
ul, ol {
  text-align: left;

  & & {
    padding: {
      bottom: 0;
      left: 0;
    }
  }
}

// style.scss
@import 'foundation/code', 'foundation/lists';

// SASS
// foundation/_code.sass
code
  padding: .25em
  line-height: 0

// SASS
// foundation/_lists.sass
ul, ol
  text-align: left

  & &
    padding:
      bottom: 0
      left: 0

// SASS
// style.sass
@import foundation/code, foundation/lists

/* CSS */
code {
  padding: .25em;
  line-height: 0;
}

ul, ol {
  text-align: left;
}
ul ul, ol ol {
  padding-bottom: 0;
  padding-left: 0;
}

When Sass imports a file, that file is evaluated as though its contents appeared directly in place of the @import. Any mixins, functions, and variables from the imported file are made available, and all its CSS is included at the exact point where the @import was written. What’s more, any mixins, functions, or variables that were defined before the @import (including from other @imports) are available in the imported stylesheet.

Finding the File

It wouldn’t be any fun to write out absolute URLs for every stylesheet you import, so Sass’s algorithm for finding a file to import makes it a little easier. For starters, you don’t have to explicitly write out the extension of the file you want to import; @import "variables" will automatically load variables.scss, variables.sass, or variables.css.

Load Paths

All Sass implementations allow users to provide load paths: paths on the filesystem that Sass will look in when resolving imports. For example, if you pass node_modules/susy/sass as a load path, you can use @import "susy" to load node_modules/susy/sass/susy.scss.

Imports will always be resolved relative to the current file first, though. Load paths will only be used if no relative file exists that matches the import. This ensures that you can’t accidentally mess up your relative imports when you add a new library.

Partials

As a convention, Sass files that are only meant to be imported, not compiled on their own, begin with _ (as in _code.scss). These are called partials, and they tell Sass tools not to try to compile those files on their own. You can leave off the _ when importing a partial.

Index Files

Compatibility:

Dart Sass

✓

LibSass

since 3.6.0

Ruby Sass

since 3.6.0

If you write an _index.scss or _index.sass in a folder, when the folder itself is imported that file will be loaded in its place.

// foundation/_code.scss
code {
  padding: .25em;
  line-height: 0;
}

// foundation/_lists.scss
ul, ol {
  text-align: left;

  & & {
    padding: {
      bottom: 0;
      left: 0;
    }
  }
}

// foundation/_index.scss
@import 'code', 'lists';

// style.scss
@import 'foundation';

// SASS
// foundation/_code.sass
code
  padding: .25em
  line-height: 0

// SASS
// foundation/_lists.sass
ul, ol
  text-align: left

  & &
    padding:
      bottom: 0
      left: 0

// SASS
// foundation/_index.sass
@import code, lists

// SASS
// style.sass
@import foundation

/* CSS */
code {
  padding: .25em;
  line-height: 0;
}

ul, ol {
  text-align: left;
}
ul ul, ol ol {
  padding-bottom: 0;
  padding-left: 0;
}

Custom Importers

All Sass implementations provide a way to define custom importers, which control how @imports locate stylesheets:

• Node Sass and Dart Sass on npm provide an importer option as part of their JS API.

• Dart Sass on pub provides an abstract Importer class that can be extended by a custom importer.

• Ruby Sass provides an abstract Importers::Base class that can be extended by a custom importer.

Nesting

Imports are usually written at the top level of a stylesheet, but they don’t have to be. They can nested within style rules or plain CSS at-rules as well. The imported CSS is nested in that context, which makes nested imports useful for scoping a chunk of CSS to a particular element or media query. Top-level mixins, functions, and variables defined in the nested import are only available in the nested context.

// _theme.scss
pre, code {
  font-family: 'Source Code Pro', Helvetica, Arial;
  border-radius: 4px;
}

// style.scss
.theme-sample {
  @import "theme";
}

// SASS
// _theme.sass
pre, code
  font-family: 'Source Code Pro', Helvetica, Arial
  border-radius: 4px

// SASS
// style.sass
.theme-sample
  @import theme

/* CSS */
.theme-sample pre, .theme-sample code {
  font-family: 'Source Code Pro', Helvetica, Arial;
  border-radius: 4px;
}

// _theme.scss
ul li {
  $padding: 16px;
  padding-left: $padding;
  [dir=rtl] & {
    padding: {
      left: 0;
      right: $padding;
    }
  }
}

// style.scss
.theme-sample {
  @import "theme";
}

// SASS
// _theme.sass
ul li
  $padding: 16px
  padding-left: $padding
  [dir=rtl] &
    padding:
      left: 0
      right: $padding

// SASS
// style.sass
.theme-sample
  @import theme

/* CSS */
.theme-sample ul li {
  padding-left: 16px;
}
[dir=rtl] .theme-sample ul li {
  padding-left: 0;
  padding-right: 16px;
}

Importing CSS

Compatibility:

Dart Sass

since 1.11.0

LibSass

partial

Ruby Sass

✗

➤

In addition to importing .sass and .scss files, Sass can import plain old .css files. The only rule is that the import must not explicitly include the .css extension, because that’s used to indicate a plain CSS @import.

// code.css
code {
  padding: .25em;
  line-height: 0;
}

// style.scss
@import 'code';

// SASS
// code.css
code {
  padding: .25em;
  line-height: 0;
}

// SASS
// style.sass
@import code

/* CSS */
code {
  padding: .25em;
  line-height: 0;
}

CSS files imported by Sass don’t allow any special Sass features. In order to make sure authors don’t accidentally write Sass in their CSS, all Sass features that aren’t also valid CSS will produce errors. Otherwise, the CSS will be rendered as-is. It can even be extended!

Plain CSS @imports

Compatibility:

Dart Sass

✓

LibSass

partial

Ruby Sass

✓

➤

Because @import is also defined in CSS, Sass needs a way of compiling plain CSS @imports without trying to import the files at compile time. To accomplish this, and to ensure SCSS is as much of a superset of CSS as possible, Sass will compile any @imports with the following characteristics to plain CSS imports:

• Imports where the URL ends with .css.
• Imports where the URL begins http:// or https://.
• Imports where the URL is written as a url().
• Imports that have media queries.

@import "theme.css";
@import "http://fonts.googleapis.com/css?family=Droid+Sans";
@import url(theme);
@import "landscape" screen and (orientation: landscape);

// SASS
@import "theme.css"
@import "http://fonts.googleapis.com/css?family=Droid+Sans"
@import url(theme)
@import "landscape" screen and (orientation: landscape)

/* CSS */
@import "theme.css";
@import "http://fonts.googleapis.com/css?family=Droid+Sans";
@import url(theme);
@import "landscape" screen and (orientation: landscape);

Interpolation

Although Sass imports can’t use interpolation (to make sure it’s always possible to tell where mixins, functions, and variables come from), plain CSS imports can. This makes it possible to dynamically generate imports, for example based on mixin parameters.

@mixin google-font($family) {
  @import url("http://fonts.googleapis.com/css?family=#{$family}");
}

@include google-font("Droid Sans");

// SASS
@mixin google-font($family)
  @import url("http://fonts.googleapis.com/css?family=#{$family}")


@include google-font("Droid Sans")

/* CSS */
@import url("http://fonts.googleapis.com/css?family=Droid Sans");

Import and Modules

Compatibility:

Dart Sass

since 1.23.0

LibSass

✗

Ruby Sass

✗

➤

Sass’s module system integrates seamlessly with @import, whether you’re importing a file that contains @use rules or loading a file that contains imports as a module. We want to make the transition from @import to @use as smooth as possible.

Importing a Module-System File

When you import a file that contains @use rules, the importing file has access to all members (even private members) defined directly in that file, but not any members from modules that file has loaded. However, if that file contains @forward rules, the importing file will have access to forwarded members. This means that you can import a library that was written to be used with the module system.

Import-Only Files

An API that makes sense for @use might not make sense for @import. For example, @use adds a namespace to all members by default so you can safely use short names, but @import doesn’t so you might need something longer. If you’re a library author, you may be concerned that if you update your library to use the new module system, your existing @import-based users will break.

To make this easier, Sass also supports import-only files. If you name a file <name>.import.scss, it will only be loaded for imports, not for @uses. This way, you can retain compatibility for @import users while still providing a nice API for users of the new module system.

// _reset.scss

// Module system users write `@include reset.list()`.
@mixin list() {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }
}

// _reset.import.scss

// Legacy import users can keep writing `@include reset-list()`.
@forward "reset" as reset-*;

// SASS
// _reset.sass

// Module system users write `@include reset.list()`.
@mixin list()
  ul
    margin: 0
    padding: 0
    list-style: none

// SASS
// _reset.import.sass

// Legacy import users can keep writing `@include reset-list()`.
@forward "reset" as reset-*

Configuring Modules Through Imports

Compatibility:

Dart Sass

since 1.24.0

LibSass

✗

Ruby Sass

✗

You can configure modules that are loaded through an @import by defining global variables prior the @import that first loads that module.

// _library.scss
$color: blue !default;

a {
  color: $color;
}

// _library.import.scss
@forward 'library' as lib-*;

// style.sass
$lib-color: green;
@import "library";

// SASS
$color: blue !default

a
  color: $color

// SASS
// _library.import.sass
@forward 'library' as lib-*

// SASS
// style.sass
$lib-color: green
@import "library"

/* CSS */
a {
  color: green;
}

Loading a Module That Contains Imports

When you use @use (or @forward) load a module that uses @import, that module will contain all the public members defined by the stylesheet you load and everything that stylesheet transitively imports. In other words, everything that’s imported is treated as though it were written in one big stylesheet.

This makes it easy to convert start using @use in a stylesheet even before all the libraries you depend on have converted to the new module system. Be aware, though, that if they do convert their APIs may well change!

Differences From @use

The @use rule is intended to replace the old @import rule, but it’s intentionally designed to work differently. Here are some major differences between the two:

• @use only makes variables, functions, and mixins available within the scope of the current file. It never adds them to the global scope. This makes it easy to figure out where each name your Sass file references comes from, and means you can use shorter names without any risk of collision.

• @use only ever loads each file once. This ensures you don’t end up accidentally duplicating your dependencies’ CSS many times over.

• @use must appear at the beginning your file, and cannot be nested in style rules. Nested imports can be migrated to mixin calls or meta.load-css().

• Each @use rule can only have one URL.

• @use requires quotes around its URL, even when using the indented syntax.