Breaking Change: @import and global built-in functions

@import causes numerous problems, requiring Sass members to be manually namespaced to avoid conflicts, slowing down compilation when the same file is imported more than once, and making it very difficult for both humans and tools to tell where a given variable, mixin, or function comes from.

The module system fixes these problems and brings Sass’s modularity up to par with the best practices of other modern languages, but we can’t get the full benefits of it while @import remains in the language.

@import is now deprecated as of Dart Sass 1.80.0. Additionally, we’re also deprecating the global versions of Sass built-in functions that are available in sass: modules.

Transition PeriodTransition Period permalink

Compatibility:

Dart Sass

since 1.80.0

LibSass

✗

Ruby Sass

✗

Sass @import rules and global built-in function calls now emit deprecation warnings. While Dart Sass 2.0.0 will be released soon with various smaller breaking changes, we don’t expect to remove Sass @import rules or global built-in functions until Dart Sass 3.0.0, which will be released no sooner than two years after Dart Sass 1.80.0.

Eventually, all @import rules will be treated as plain CSS @imports, likely after an intermediate period where anything that used to be a Sass @import throws an error.

Automatic MigrationAutomatic Migration permalink

You can use the Sass migrator to automatically update your stylesheets to use the module system.

$ npm install -g sass-migrator
$ sass-migrator module --migrate-deps your-entrypoint.scss

If you want to migrate away from global built-in functions, but aren’t yet ready to fully migrate your @import rules, you can pass the --built-in-only flag to migrate the functions while leaving @import rules as-is.

Migration RecipesMigration Recipes permalink

Nested ImportsNested Imports permalink

While @import can be used within CSS rules, @use has to be written at the top level of a file (this is because each @used module’s CSS is only included in the output once, so it wouldn’t make sense to allow it both in a nested context and the top level). There are two ways to migrate nested @imports to the module system:

1. The recommended way, which requires a little more up-front effort, is to wrap all the CSS emitted by your nested modules in mixins and @include those mixins in the nested context. This matches the way most other programming languages work, where each file defines a function or class that gets called by the files that use it, and it makes it very clear exactly how you expect that file to be used. It also makes it easier to add configuration, since you can just pass parameters or even @content blocks to the mixin.

2. A more direct translation is to use the meta.load-css() mixin to directly load the module’s CSS where you want to use it. This is appropriate when you don’t have control over the file you’re loading to create a mixin wrapper. Note that meta.load-css() fully compiles the CSS before it does any nesting, so any parent selectors won’t "see" the rules outside the meta.load-css() call.

Configured ThemesConfigured Themes permalink

A pattern that people sometimes use with @import is to have a component library full of partials that all use the same variables without explicitly loading them, and then having several different "theme" entrypoints that define different values for those variables to provide different visual themes. They may either define the variables directly, or override defaults of a base theme partial. As a simplified example:

// components/_button.scss
button {
  color: $text-color;
  background-color: $background-color;
}

// _theme.scss
$text-color: black !default;
$background-color: white !default;

// dark.scss
$text-color: white;
$background-color: white;
@import "theme";

@import "components/button";
// More components are usually imported here.

// components/_button.scss
button
  color: $text-color
  background-color: $background-color

// _theme.scss
$text-color: black
$background-color: white

// dark.scss
$text-color: white
$background-color: white
@import "theme"

@import "components/button"
// More components are usually imported here.

button {
  color: white;
  background-color: black;
}

In the module system, the component partials need to explicitly reference the variables they refer to. But this doesn’t mean this kind of theming doesn’t work! Because @use-ing the same module multiple times always uses the same configuration, if you configure it once in the entrypoint and all other uses will see that configuration:

// components/_button.scss
@use "../theme";

button {
  color: theme.$text-color;
  background-color: theme.$background-color;
}

// _theme.scss
$text-color: black !default;
$background-color: white !default;

// dark.scss
@use "theme" with (
  $text-color: white,
  $background-color: white,
);

@use "components/button";
// More components are usually imported here.

// components/_button.scss
@use "../theme"

button
  color: theme.$text-color
  background-color: theme.$background-color

// _theme.scss
$text-color: black !default
$background-color: white !default

// dark.scss
@use "theme" with (
  $text-color: white,
  $background-color: white,
)

@use "components/button"
// More components are usually imported here.

button {
  color: white;
  background-color: black;
}

Can I Silence the Warnings?Can I Silence the Warnings? permalink

Sass provides a powerful suite of options for managing which deprecation warnings you see and when.

Terse and Verbose ModeTerse and Verbose Mode permalink

By default, Sass runs in terse mode, where it will only print each type of deprecation warning five times before it silences additional warnings. This helps ensure that users know when they need to be aware of an upcoming breaking change without creating an overwhelming amount of console noise.

If you run Sass in verbose mode instead, it will print every deprecation warning it encounters. This can be useful for tracking the remaining work to be done when fixing deprecations. You can enable verbose mode using the --verbose flag on the command line, or the verbose option in the JavaScript API.

Silencing Deprecations in DependenciesSilencing Deprecations in Dependencies permalink

Sometimes, your dependencies have deprecation warnings that you can’t do anything about. You can silence deprecation warnings from dependencies while still printing them for your app using the --quiet-deps flag on the command line, or the quietDeps option in the JavaScript API.

For the purposes of this flag, a "dependency" is any stylesheet that’s not just a series of relative loads from the entrypoint stylesheet. This means anything that comes from a load path, and most stylesheets loaded through custom importers.

Silencing Specific DeprecationsSilencing Specific Deprecations permalink

If you know that one particular deprecation isn’t a problem for you, you can silence warnings for that specific deprecation using the --silence-deprecation flag on the command line, or the silenceDeprecations option in the JavaScript API.

Note: While the deprecations for @import and global built-ins are being released together and we expect both features to be removed simultaneously as well (in Dart Sass 3.0.0), they are considered separate deprecations for the purpose of the API. If you wish to silence both @import deprecation warnings and global built-in deprecation warnings, you’ll need to pass both import and global-builtin to --silence-deprecation/silenceDeprecations.