Bird
Raised Fist0
SASSmarkup~3 mins

Why @import to @use migration in SASS? - Purpose & Use Cases

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

Discover how a simple change in Sass can save you hours of debugging and speed up your website!

The Scenario

Imagine you have many Sass files for colors, fonts, and layouts. You use @import to bring them all together in one main file.

The Problem

When your project grows, @import causes files to load multiple times, making your CSS bigger and slower. It also mixes variables and functions, causing confusion and bugs.

The Solution

The new @use rule loads files only once and keeps variables and functions organized. It helps you avoid conflicts and makes your styles easier to manage.

Before vs After
Before
@import 'colors';
@import 'fonts';
After
@use 'colors';
@use 'fonts';
What It Enables

You can build faster, cleaner stylesheets that are easier to maintain and less error-prone.

Real Life Example

Think of a big website where many developers add styles. Using @use helps everyone avoid overwriting each other's work and keeps the design consistent.

Key Takeaways

@import loads files multiple times and mixes styles.

@use loads files once and keeps styles organized.

Switching to @use makes your Sass projects faster and clearer.

Practice

(1/5)
1. What is the main advantage of using @use instead of @import in Sass?
easy
A. It allows importing CSS files directly without processing.
B. It loads files only once and uses namespaces to avoid conflicts.
C. It automatically compiles Sass to CSS without a compiler.
D. It enables inline JavaScript execution inside Sass files.

Solution

  1. Step 1: Understand @import behavior

    @import loads files multiple times and merges all variables globally, which can cause conflicts.
  2. Step 2: Understand @use improvements

    @use loads files only once and requires a namespace prefix, preventing variable and mixin conflicts.
  3. Final Answer:

    It loads files only once and uses namespaces to avoid conflicts. -> Option B
  4. Quick Check:

    @use = safer, namespaced imports [OK]
Hint: Remember: @use loads once with namespaces [OK]
Common Mistakes:
  • Thinking @use imports CSS files directly
  • Assuming @use runs JavaScript
  • Believing @use compiles Sass automatically
2. Which of the following is the correct syntax to replace @import 'colors'; with @use and a namespace c?
easy
A. @use 'colors' as c;
B. @use colors as 'c';
C. @use 'colors' namespace c;
D. @use 'colors' with c;

Solution

  1. Step 1: Recall @use syntax

    The correct syntax is @use 'filename' as namespace; with quotes around filename and as keyword.
  2. Step 2: Match options

    @use 'colors' as c; matches the correct syntax exactly: @use 'colors' as c;.
  3. Final Answer:

    @use 'colors' as c; -> Option A
  4. Quick Check:

    Correct @use syntax = @use 'colors' as c; [OK]
Hint: Use quotes and 'as' keyword for namespace [OK]
Common Mistakes:
  • Omitting quotes around filename
  • Using 'namespace' instead of 'as'
  • Placing namespace inside quotes
3. Given the Sass files:
// _variables.scss
$primary-color: blue;

// styles.scss
@use 'variables' as vars;
.button {
  color: vars.$primary-color;
}

What color will the button text be in the compiled CSS?
medium
A. blue
B. vars.$primary-color
C. undefined
D. red

Solution

  1. Step 1: Understand variable access with @use

    The variable $primary-color is accessed with the namespace prefix vars.$primary-color.
  2. Step 2: Check variable value

    In _variables.scss, $primary-color is set to blue, so the button color will be blue.
  3. Final Answer:

    blue -> Option A
  4. Quick Check:

    Namespace prefix accesses variable value correctly [OK]
Hint: Use namespace prefix to get variable value [OK]
Common Mistakes:
  • Using variable without namespace prefix
  • Expecting variable name as string output
  • Assuming default color red
4. What is wrong with this Sass code after migrating from @import to @use?
@use 'mixins';
.button {
  @include border-radius(5px);
}
medium
A. Cannot use @include with @use.
B. Incorrect quotes around filename in @use.
C. Missing namespace prefix before border-radius mixin.
D. Mixin name should be borderRadius instead.

Solution

  1. Step 1: Understand @use namespace requirement

    When using @use, all variables and mixins must be accessed with the namespace prefix unless configured otherwise.
  2. Step 2: Identify missing prefix

    The code calls @include border-radius(5px); without prefix. It should be @include mixins.border-radius(5px);.
  3. Final Answer:

    Missing namespace prefix before border-radius mixin. -> Option C
  4. Quick Check:

    @use requires namespace prefix [OK]
Hint: Add namespace prefix to mixin calls [OK]
Common Mistakes:
  • Calling mixins without namespace prefix
  • Confusing quotes usage in @use
  • Thinking @include is disallowed
5. You have two Sass files:
// _colors.scss
$primary: red;

// _theme.scss
@use 'colors' as c;
$primary: blue !default;

// styles.scss
@use 'theme' as t;
.button {
  color: t.$primary;
}

What color will the button text be and why?
hard
A. blue, because $primary in theme overrides colors with !default.
B. blue, because @use merges variables without namespaces.
C. red, because !default prevents override in theme.
D. red, because $primary in colors overrides !default in theme.

Solution

  1. Step 1: Understand !default behavior

    The !default flag sets a variable only if it is not already set.
  2. Step 2: Analyze variable values

    $primary in colors is red. In theme, $primary is set to blue !default, so it will only be set if $primary was not already set.
  3. Step 3: Check namespaces and usage

    theme uses colors as c, so $primary from colors is already set. Therefore, blue !default does not override red.
  4. Final Answer:

    red, because $primary in colors overrides !default in theme. -> Option D
  5. Quick Check:

    !default only sets if variable is unset, so red stays [OK]
Hint: Remember !default sets only if variable is unset [OK]
Common Mistakes:
  • Assuming !default always overrides
  • Ignoring namespaces in variable access
  • Thinking variables merge without prefixes