Sass Modules: Using @use for Clean, Scoped Styles
Think of @use as importing a JavaScript module. It loads Sass variables and mixins into a private namespace, preventing global style conflicts. Use it to structure large CSS codebases by breaking styles into logical partials.
Why it exists
The old @import rule in Sass made all variables, mixins, and functions from imported files globally available. This led to naming collisions and made it difficult to trace where a style came from in large projects. It was impossible to know which dependencies a file truly had.
The mental model
Treat @use like an ES6 import statement in JavaScript. You are explicitly loading a "module" (another Sass file) and its members (variables, mixins, functions) become available only within the current file, under a specific namespace. This makes dependencies clear and prevents styles from leaking into the global scope. Files intended only for import are called "partials" and their names start with an underscore, like _variables.scss.
How it works
When you write @use 'src/corners', Sass loads the file _corners.scss. It makes any variables, mixins, or functions in that file accessible via a namespace, which defaults to the filename (corners). For example, a variable radius in _corners.scss is accessed as corners.radius. A mixin rounded is included with @include corners.rounded. Importantly, the CSS from a module is included in the final output only once, no matter how many other modules @use it.
When to use it
Use @use as the default way to structure any modern Sass project. It's essential for building design systems, component libraries, or any large-scale application where you need to manage dependencies cleanly. It allows you to create small, focused partial files for things like colors, typography, or individual components, and then compose them together safely.
When not to use it
The primary reason not to use @use is for compatibility with older Sass compilers. Only Dart Sass supports @use; LibSass and the old Ruby Sass do not. If your project is stuck on an older build toolchain that uses LibSass, you'll have to stick with the legacy @import rule and its associated problems. All @use rules must also appear at the top of a file, before any style rules.
One canonical example
To create a reusable, rounded button, you first define your corner styles in a partial file. File: _corners.scss $radius: 3px; @mixin rounded { border-radius: $radius; }
Then, in your main stylesheet, you @use the partial and apply its members using the namespace. File: style.scss @use 'corners'; .button { @include corners.rounded; padding: 5px + corners.$radius; }
This compiles to CSS where the button has a 3px border-radius and 8px of padding, without making $radius or rounded globally available.
Interview question
What is the primary advantage of using Sass's @use rule over the legacy @import?
- a.It automatically optimizes and minifies the CSS output from imported files.
- b.It prevents naming conflicts by scoping variables, mixins, and functions to a private namespace.Correct
- c.It allows for dynamic loading of Sass modules based on runtime conditions.
- d.It guarantees that the CSS from a module is only compiled once, even if used in multiple places.
Why? this is the answer
The card explicitly states that @import led to "naming collisions" due to global availability, and @use solves this by making members available "under a specific namespace," preventing "styles from leaking into the global scope." While @use does ensure CSS is compiled once, the core problem it addresses is naming conflicts.
Just read this? Test yourself on what you have been reading.
Read the original → sass-lang.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles