(This is my first article...so cut me some slack)
Recently while doing some research for a problem I had, I stumbled upon something that took me by surprise. Sass is removing support
@import in favor of
@use! I was amazed that I had not seen anything mentioned outside the Sass documentation, so naturally I started doing a little more digging.
Well, it is part of the new Module System that was launched by the Sass team on October 1st 2019. The goal of this new at-rule is to address some issues that have been caused by the current
@import rule when importing "modules" in Sass. Let's first take a look at some of the issues caused by the
@import rule and how it will be solved by
When including modules with
@use, those member names are only available in the stylesheet that they are included in. With the
@import rule, the member names are available to every other stylesheet downstream of it's inclusion.
When a stylesheet is imported multiple times that is how many times it will be included in your project. When importing with
@use, these sheets are only included and executed once.
Any members which begin with
_ are considered private and are only available to the styleshee that they are included in with
@use. This was not available with
@import at all. Imported utilities with
@use can be kept private even when other stylesheets import the sheet using those utilities. This is handled with the new
@forward rule included with the new module system.
Styles applied with
@extend are only applied to the stylesheet it imports and not stylesheets that import it.
With the new module system, the Sass team is also removing global functions and replacing them with built-in modules. This is similar to built-in module usage in Node, Python, etc. These built-in modules are:
These built in modules will have similar functions to the current global functions, however some of the implementations will be a little different. The biggest change here is that in order to use these functions, the built-in module will need to be included with
@use where it needs to be executed.
@use rule is available in Dart Sass v1.23.0 only. It is not yet available with LibSass (which also means no Node Sass implementation) or Ruby Sass (which has reached its EOL anyhow...RIP 💀). This means that if you would like to start testing out the
@use rule, you will need to convert your project to use Dart Sass if it does not already. I mostly work in Angular, and since the v8.0.0 release Angular now uses Dart Sass, where before it was just an option. Dart Sass is also the primary implementation of Sass, which means if you want all of the shiny new features you should make the switch. Outside of that, the only hiccup that I ran into is that the extensions I use in VSCode do not currently know how to handle the
@use (and subsequently the
@forward) rules when written in the editor.
For larger projects this can be quite the undertaking to switch all of the import statements to utilize the new
@use rule. Never fear, you can install the sass-migrator package from NPM which will help do some of the heavy lifting here.
There is also plenty of time to do this so that you can slowly switch over your imports to this new module system over time. The Sass team has made it clear that they have taken into consideration the effort that would be needed to change products over to this. The new module system is backwards-compatible between
@use, and nothing has been deprecated or removed just yet. According to their recent blog post here is the timeframe and/or criteria that needs to be met prior to deprecation and removal of the current system:
Deprecated: This will be done after
@usehas been supported in Dart Sass and LibSass for one year or two years after Dart Sass launches support for
@use(which it has). This will happen no later than October 1st, 2021.
Support dropped and/or removed: This will happen one year after deprecation goes into effect. This will occur no later than October 1st 2022.
This means that there will be, at the very least, two to three more years of support for
@import to be used alongside
@use while you convert your applications over.
In the next few parts we will take a look at how
@use solves some of the issues that exist with
@import and provide some more functionality and control when working with modules.