Breaking Change: Private Configuration
When Sass introduced the new module system, it also introduced the concept of private variables that were meant only to be visible or modifiable within the module. But there was an accidental loophole: this variables could still be configured.
It’s possible to write @use "module" with ($-private: value)
and affect the
value of a module’s private variable. This goes against the intended behavior of
the language, and likely against the module author’s intentions as well. To
close this loophole, we’re moving towards making it an error to ever configure a
private variable.
We still plan to allow private variables to be declared with !default
, because
this remains a useful way to assign a value only if the variable is currently
null
(similar to ??=
assignment in JavaScript).
⚠️ Heads up!
Any variable whose name starts with -
or _
is considered private,
including variables whose names start with --
. For this reason, we
discourage the use of CSS custom property-style names for Sass variables.
Phase 1Phase 1 permalink
- Dart Sass
- since 1.92.0
- LibSass
- ✗
- Ruby Sass
- ✗
Currently, Dart Sass emits a deprecation warning if you use a private variable
name in a configuration, but it will still allow that variable to be configured
if the module declares it with !default
.
To fix any violations, change all variables that are intended to be configured
to no longer be private by removing all leading -
or _
characters.
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.
Phase 2Phase 2 permalink
- Dart Sass
- ✗
- LibSass
- ✗
- Ruby Sass
- ✗
In Dart Sass 2.0.0, including a private variable in a configuration will be an error.