@import to @use migration in SASS - Deep Dive

Overview - @import to @use migration

What is it?

@import and @use are ways to include styles from one Sass file into another. @import was the old method, but it has problems like loading files multiple times and polluting the global style space. @use is the new, recommended way that loads files once and keeps styles organized and scoped. Migrating means changing your Sass code from @import to @use to get better performance and clearer code.

Why it matters

Without migrating to @use, your stylesheets can become slow and hard to maintain because @import loads files repeatedly and mixes all styles globally. This can cause bugs and make your project grow messy. Using @use helps keep styles modular and efficient, making your website faster and easier to update.

Where it fits

Before learning this, you should know basic Sass syntax and how @import works. After this, you can learn about Sass modules, namespaces, and advanced features like mixins and functions with @use.

Mental Model

Core Idea

@use loads a Sass file once and keeps its styles in a private box, while @import loads files multiple times and mixes all styles globally.

Think of it like...

Imagine @import as pouring all your paint colors into one big bucket, mixing them all together, which can get messy. @use is like keeping each paint color in its own labeled jar, so you only use what you need without mixing everything.

┌───────────────┐       ┌───────────────┐
│  main.scss    │       │  main.scss    │
│               │       │               │
│ @import a.scss│       │ @use a.scss   │
└──────┬────────┘       └──────┬────────┘
       │                        │
       ▼                        ▼
┌───────────────┐       ┌───────────────┐
│  a.scss       │       │  a.scss       │
│ (loaded each  │       │ (loaded once, │
│  time imported)│      │  scoped styles)│
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding @import basics

Concept: Learn how @import includes one Sass file into another and what it does.

In Sass, @import lets you bring styles from another file into your current file. For example, @import 'colors'; will include all styles from colors.scss. This helps split styles into smaller files. But @import copies the content every time it is used, which can cause duplication.

Result

Your styles from the imported file appear in the final CSS as if they were written in the main file.

Understanding @import is key because it shows why loading files multiple times can slow down your project and cause style conflicts.

2

Foundation

Introducing @use for modular styles

Concept: @use loads a Sass file once and keeps its styles private unless explicitly shared.

@use 'colors'; loads colors.scss only once. Unlike @import, it does not copy styles everywhere. Instead, it creates a namespace (like colors.) to access variables or mixins. This keeps styles organized and avoids conflicts.

Result

Styles from colors.scss are available under the colors namespace, preventing accidental overwrites.

Knowing that @use creates a private box for styles helps you write safer and clearer Sass code.

3

Intermediate

Namespaces and accessing styles

🤔Before reading on: do you think you can use variables from a @use file without prefixing the namespace? Commit to your answer.

Concept: Learn how to access variables, mixins, and functions from a @use file using namespaces.

When you @use a file, you must prefix its variables or mixins with the namespace. For example, if you @use 'colors'; and colors.scss has $primary: blue;, you access it as colors.$primary. This avoids naming clashes.

Result

You can safely use styles from multiple files without overwriting each other.

Understanding namespaces prevents bugs caused by variables or mixins with the same name in different files.

4

Intermediate

Using 'as *' to simplify namespaces

🤔Before reading on: do you think using 'as *' removes all namespace prefixes? Commit to your answer.

Concept: Learn how to remove namespaces with @use 'file' as * to access styles directly.

You can write @use 'colors' as *; to use variables without the colors. prefix. But this can cause conflicts if multiple files have the same names. Use it carefully.

Result

Variables and mixins are accessible directly, but risk name clashes.

Knowing when to use 'as *' helps balance convenience and safety in your styles.

5

Intermediate

Migrating variables from @import to @use

🤔Before reading on: do you think variables from @import are global or scoped? Commit to your answer.

Concept: Understand how variables behave differently when moving from @import to @use.

With @import, variables are global and accessible everywhere. With @use, variables are scoped under namespaces. To migrate, you must update your code to use the namespace prefix or use 'as *' carefully.

Result

Your variables work correctly without polluting the global scope.

Knowing variable scoping differences prevents broken styles after migration.

6

Advanced

Handling mixins and functions in migration

🤔Before reading on: do you think mixins from @import require namespace prefixes after @use? Commit to your answer.

Concept: Learn how to update mixins and functions usage when migrating to @use.

Mixins and functions imported with @import are global. With @use, you must prefix them with the namespace, like colors.mixin-name(); Update your calls accordingly.

Result

Mixins and functions work without conflicts or errors.

Understanding this avoids runtime errors and keeps your styles modular.

7

Expert

Avoiding circular dependencies in @use

🤔Before reading on: do you think @use allows circular imports without issues? Commit to your answer.

Concept: Learn why circular dependencies cause errors with @use and how to fix them.

@use loads files once and caches them. If two files @use each other, Sass throws an error. To fix, restructure your files to remove circular references or combine shared code into a separate file.

Result

Your Sass compiles without circular import errors.

Knowing this prevents a common migration pitfall that can break your build.

Under the Hood

@use works by loading a Sass file once per compilation and creating a module namespace. It caches the loaded file to avoid duplication. Variables, mixins, and functions inside the file are scoped to this namespace, preventing global pollution. This contrasts with @import, which copies the file content every time it is called, merging all styles globally.

Why designed this way?

@use was designed to fix problems with @import such as slow compilation, duplicated styles, and global namespace pollution. By introducing modules and namespaces, Sass encourages better code organization and performance. Alternatives like keeping @import were rejected because they caused maintenance headaches and bugs in large projects.

┌───────────────┐
│  main.scss    │
│ @use colors;  │
└──────┬────────┘
       │ loads once
       ▼
┌───────────────┐
│  colors.scss  │
│ $primary: blue│
│ mixin button  │
└───────────────┘
       │
       ▼
┌─────────────────────────────┐
│ Namespace 'colors' created   │
│ Access with colors.$primary  │
│ and colors.button() mixin    │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does @use load the same file multiple times like @import? Commit to yes or no.

Common Belief: Many think @use behaves just like @import and loads files multiple times.

Reality: @use loads each file only once per compilation and caches it, improving performance.

Why it matters: Believing @use duplicates files can cause confusion and prevent adopting the better method.

Quick: Can you use variables from a @use file without prefixing the namespace? Commit to yes or no.

Common Belief: Some believe variables from @use files are global and accessible without prefixes.

Reality: Variables are scoped under the namespace and require prefixing unless 'as *' is used.

Why it matters: Assuming global access leads to errors and broken styles after migration.

Quick: Does @use allow circular imports without errors? Commit to yes or no.

Common Belief: Some think circular imports work fine with @use as they did with @import.

Reality: @use throws errors on circular dependencies because it caches files and cannot resolve loops.

Why it matters: Ignoring this causes build failures and confusion during migration.

Quick: Does using 'as *' with @use always improve code clarity? Commit to yes or no.

Common Belief: Many believe 'as *' is always better because it removes namespace prefixes.

Reality: 'as *' can cause naming conflicts and reduce the modular benefits of @use.

Why it matters: Overusing 'as *' can reintroduce problems @use was designed to solve.

Expert Zone

1

Using @forward in combination with @use allows creating public APIs for Sass modules, controlling what is exposed to other files.

2

The order of @use statements matters because Sass loads files once and caches them, so side effects in modules can affect others.

3

You can configure namespaces with aliases in @use, which helps when importing multiple modules with similar names.

When NOT to use

@use is not suitable if you rely heavily on global variables or legacy code that cannot be refactored easily. In such cases, maintaining @import temporarily or using build tools to manage legacy styles might be better.

Production Patterns

In production, teams use @use with @forward to build modular style libraries. They namespace all variables and mixins to avoid conflicts and improve maintainability. Build tools often enforce no @import usage to ensure consistent performance.

Connections

JavaScript ES6 Modules

@use in Sass is similar to ES6 import/export modules in JavaScript.

Understanding how JavaScript modules scope and share code helps grasp Sass @use namespaces and single loading.

Software Encapsulation

@use enforces encapsulation by hiding styles inside namespaces.

Knowing encapsulation principles from software engineering clarifies why @use prevents global style pollution.

Library Management in Package Managers

Like package managers avoid duplicate downloads, @use caches files to avoid repeated loading.

Recognizing caching and deduplication patterns in package management helps understand @use's performance benefits.

Common Pitfalls

#1 Using @import and @use together without understanding their differences.

Wrong approach:

@import 'colors';
@use 'colors';

Correct approach:

@use 'colors';

Root cause:

Confusion about how @import and @use interact leads to redundant or conflicting style loads.

#2 Accessing variables from a @use file without namespace prefix.

Wrong approach:

$main-color: $primary-color;

Correct approach:

$main-color: colors.$primary-color;

Root cause:

Not realizing @use scopes variables under namespaces causes undefined variable errors.

#3 Creating circular dependencies by having two files @use each other.

Wrong approach:

// a.scss
@use 'b';

// b.scss
@use 'a';

Correct approach:

// Combine shared code into c.scss
// a.scss
@use 'c';

// b.scss
@use 'c';

Root cause:

Lack of understanding that @use caches files and cannot resolve circular imports.

Key Takeaways

@use is the modern way to include Sass files, loading each file once and keeping styles scoped.

Namespaces created by @use prevent style conflicts and make your code more maintainable.

Migrating from @import to @use requires updating variable and mixin references to use namespaces.

Avoid circular dependencies with @use by restructuring your Sass files carefully.

Using @use improves performance and clarity, making your stylesheets easier to work with and faster to compile.

Practice

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