Breaking Change: Functions and Mixins Beginning with –

Prior to Dart Sass 1.76.0, function and mixin names could be any valid CSS identifier, but identifiers beginning with -- are now deprecated.

Generally, Sass allows any valid CSS identifier to be used for any Sass definition. This includes identifiers which begin with --, which users may be most familiar with in the context of CSS custom properties. However, the CSS working group is seriously considering adding built-in support to CSS itself for functions and mixins, likely using at-rules named @mixin and @function just like Sass.

This means that Sass, in order to preserve its core design principle of CSS compatibility while still supporting Sass’s build-time functions and mixins, needs to be able to distinguish between CSS and Sass declarations that use the same at-rule names. Fortunately, although the details of the syntax CSS uses for functions and mixins is still very much up in the air, one point seems uncontroversial: the use of custom-property-like identifiers beginning with -- for CSS mixin and function names.

This will allow Sass to distinguish plain-CSS functions and mixins as those that begin with --. But in order for this to work, we first have to disallow Sass functions and mixins from using that prefix.

Transition PeriodTransition Period permalink

Dart Sass: since 1.76.0
LibSass: ✗
Ruby Sass: ✗

Between Dart Sass 1.76.0 and Dart Sass 2.0.0, Dart Sass will continue to allow functions and mixins whose names begin with --. However, it will emit a deprecation warning named css-function-mixin.

Between Dart Sass 2.0.0 and the release of Dart Sass’s support for plain CSS functions and mixins, functions and mixins will not be allowed to have names that begin with --.

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.