0 comment

What’s new with SASS in SPFx 1.16.0

Change for SASS in SPFx infgraphic
It’s been some time until finally sass-dart, and now only as sass arrived in the SharePoint Framework. With this upgrade, you can use the latest language improvement in SASS. This upgrade is only available in all new SharePoint Online Projects.

SASS based on Dart the background

Before SASS got rewritten in a programming language named Dart it was based on a C/C++ implementation. The downside was that every project needed to cross-compile a library called lib-sass.

Since 2018 lib-sass has had some trouble keeping up with the latest language developments in SASS. It was clear that SASS-dart was the way forward, and many web developers had already switched to this new library.

Finally, two years ago, on October 26th 2020, libSass got deprecated.


It is not a versus between those two, but CSS is improving at a pace that is hard to follow up sometimes. Not only will new features be introduced in CSS a couple of times a year, but monthly, at least one new feature will land in our browsers.

These features had some conflicting nomenclature with how you write code in SASS. For example, a simple calculation looked like this when not done in browsers.

font-size: 1rem / 4; /* RESULT: 0.25rem ***/

In this case, the value of 1rem gets divided by 4 – SASS did the calculation. Of course, the browser could do it in this form calc(1rem / 4). The calculation might have an impact on the performance.
The following code demonstrates another case where the forward slashes mean something completely different.

grid-column: 1 / 3;

The code above defines that an element on a grid should span from the first to the third column. We see the forward slash again here, but nothing should get divided here.

In this case, SASS need to make an educated guess about when to apply a math rule to the code and when it should leave the code untouched. It confused not only the compiler, which has always treated it well but even designers.

What you now need to use to clarify is the following. So let’s transform the example from before.

@use 'sass:math'; /** Imports the math module of SASS */

font-size: math.div(1rem, 4); /* RESULT: 0.25rem ***/

The first thing you must do in your code is import SASS’s math module via the keyword @use. Then the calculation needs to be accomplished by a function called math.div to divide 1rem by 4.
This change led to better code in general and SASS, the programming language, followed a new, better approach.

By the way, the @use statement also allows importing external or partial SASS files. @import always led to the same confusion as the division of elements.

In future, we also have to consider more things like this in our code. Another conflict of interest between SASS and CSS got introduced with Media Queries Level 4.

@use statement combined with CSS Modules

Another thing that exists in SASS, as well as CSS, is the @import which allows you to import files from a CDN in a CSS fashion or a partial SASS file. SASS treated the files differently depending on their context.

@import in the newest SASS version got deprecated again, not fully removed and still supported, but it gets removed overall at some point. Consider the following case.


@import 'node_modules/the-all-awesome-htwoo'


The :global CSS Module declaration left all the files to import untouched because otherwise, an external framework would not be able to work with SPFx. On the other hand, we like to have the incoming CSS scope with our web part code. The result of the compiled CSS looks like this.

.myNewWebPart_123456 .anotherClassFromAnotherFamework{
font-size: 1rem;

With @import this is possible. Not with the @use statement anymore. The use statement always needs to come as the first statement in SASS. So the code needs to change like this.

@use 'node_modules/the-all-awesome-htwoo';

content: "My Other Code"

So now every 3rd party code will end up as a global style sheet with all the potential side effects.

For now, it is not a problem since @import is fully supported, but this might be an issue in the future. A solution to get rid of CSS modules.

More on that on “What’s wrong with @import?“.

SASS warnings in the SharePoint Framework

There are many things to consider when architecting your style sheet nowadays. CSS improvements, SASS improvements, and sometimes you might not have access to the code.

In this case, you will see several deprecation warnings on your console.

Console output of deprecation warnings

Console output of deprecation warnings

In 1.15, those deprecation warnings also got raised directly from code in SPFx to re-configuration of SPFx this is not the code anymore. For 3rd party libraries, these warnings still get raised.

The good thing is that we can finally suppress these warnings in SPFx. Put the following file in the config folder of your project and name it ‘sass.json’.

"$schema": "",
"quietDeps": true

This setting avoids raising all warnings, as seen before, for all external packages.

Another option is ‘quiet‘, which will allow you to see deprecation warnings in your code, but rush-stack package does not expose this configuration option.

Migrate your SASS code in SPFx

Deprecation warnings in your code are now quiet by default; 3rd party code warnings can get silenced.

What does this mean for your existing code when you upgrade a project to 1.16? SASS does a great job on their communication and is open about it. In SASS, you should familiarise yourself with upcoming and current breaking changes.

They also provide a tool for migration named sass-migrator. Apply this to your project, and you can directly migrate your existing code or run a dry run without making changes. This way, you can ensure that your CSS runs in future without any problems.

Leave a Reply

Required fields are marked *.

This site uses Akismet to reduce spam. Learn how your comment data is processed.