Breaking Change: Misplaced Rest Arguments

Sass has historically allowed rest arguments to appear anywhere in an argument list, even though they’re always evaluated at the end. This closes that loophole and requires rest arguments to appear at the end of argument lists.

Dart Sass: since 1.91.0
LibSass: ✗
Ruby Sass: ✗

Rest arguments in Sass (written $args...) were always intended to be written at the end of argument lists. The way they’re evaluated reflects this: they’re always run after all the other arguments, and they’re always added to the end of the list of positional arguments.

However, due to an oversight in the implementation of both Ruby Sass and Dart Sass, this was never enforced. It was possible to write a function call like rgb([1, 2]..., 3) with the rest argument before a positional (or named) argument. This didn’t work how it looks, though: it was parsed the same as rgb(3, [1, 2]...) and resulted in the color value rgb(3, 1, 2).

💡 Fun fact:

Note that parameter declarations in the @function and @mixin rules have always required rest parameters to appear at the end. They aren’t affected by this deprecation.

To eliminate this confusion and potentially open a path towards supporting more sensible behavior for rest arguments in the future, we’re making changes in multiple phases:

Phase 1Phase 1 permalink

Dart Sass: since 1.91.0
LibSass: ✗
Ruby Sass: ✗

Currently, Dart Sass emits a deprecation warning if you use a rest argument anywhere other than at the end of an argument list.

To fix any violations and preserve the existing behavior, just move the rest argument to the end of the argument list. You might want to check to make sure that you weren’t expecting it to do something different than it actually does when you first wrote the code, though!

Phase 2Phase 2 permalink

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In Dart Sass 2.0.0, using a rest argument anywhere other than at the end of an argument list will be a syntax error.

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.