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.
⚠️ Heads up!
This option is only available in the modern JS API.