Breaking Change: `@import` and global built-in functions

Originally, Sass used @import rules to load other files with a single global namespace, with all built-in functions also available globally. We’re deprecating both Sass @import rules and global built-in functions now that the module system (@use and @forward rules) has been available for several years.

@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

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.

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.

⚠️ Heads up!

When running from the JS API, Sass doesn’t share any information across compilations, so by default it’ll print five warnings for each stylesheet that’s compiled. However, you can fix this by writing (or asking the author of your favorite framework’s Sass plugin to write) a custom Logger that only prints five errors per deprecation and can be shared across multiple compilations.

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.