@import to @use migration in SASS - Browser Rendering Trace

Render Flow - @import to @use migration

Read @import statement

→Fetch and insert file content

↓

Potential conflicts if names clash

↓

Read @use statement

→Fetch file content as module

↓

Explicit access via namespace

→Avoid global conflicts

The browser or Sass compiler reads @import by inserting the file content globally, which can cause conflicts. @use loads the file as a module with its own namespace, preventing conflicts and improving clarity.

Render Steps - 3 Steps

Code Added:@import 'colors';

Before

[No variables available]
.button { color: undefined; }

→

After

[Variables from colors.scss available globally]
.button { color: $primary-color; }

@import brings all variables and mixins from colors.scss into the global scope, so $primary-color is accessible anywhere.

🔧 Browser Action:Sass compiler reads colors.scss and merges its content globally.

Code Sample

Shows how a Sass file using @import to bring in variables globally is migrated to @use with namespace, requiring explicit prefix to access variables.

SASS

@import 'colors';

.button {
  color: $primary-color;
}

// Migrated to

@use 'colors' as c;

.button {
  color: c.$primary-color;
}

Render Quiz - 3 Questions

After applying step 2, how must you access the $primary-color variable?

A With the namespace prefix, like c.$primary-color

B Directly as $primary-color without prefix

C Using @import again

D By redefining the variable locally

Common Confusions - 2 Topics

Why does $primary-color become undefined after switching from @import to @use?

Because @use loads files as modules with namespaces, variables are no longer global. You must prefix variables with the namespace (e.g., c.$primary-color).

💡 If variables are undefined, check if you need to add the namespace prefix after @use.

Can I still use variables without a namespace after @use?

No, @use requires explicit namespace to avoid conflicts. You can rename the namespace to something shorter if needed.

💡 Use @use 'file' as alias; then access variables as alias.$variable.

Property Reference

Directive	Scope	Namespace	Conflict Risk	Usage Style
@import	Global	None	High (variables can clash)	Variables accessible directly
@use	Module	Required or optional alias	Low (namespaced access)	Variables accessed with namespace prefix

Concept Snapshot

@import loads Sass files globally, merging variables and mixins into one scope. @use loads files as modules with namespaces, requiring explicit prefixes. @use prevents variable conflicts and improves code clarity. Migrating means replacing @import with @use and adding namespace prefixes. Use aliases to shorten namespaces if needed.

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