Why you should use @use instead of @import in Angular Projects

Before the introduction of @use, developers used @import to bring styles from different files into one. However, @import had some issues:

• It could import the same file multiple times, leading to bloated CSS.

• It pulled in everything from the imported file, even unused styles.

• It caused naming conflicts when multiple files had variables with the same name.

To fix these, Sass introduced @use, which:

✔ Loads each file only once.
✔ Uses namespaces to avoid variable conflicts.
✔ Helps make CSS more optimized by importing only what’s needed.

Example: @ import (Old way)

// colors.scss
$primary-color: blue;
$secondary-color: red;


// styles.scss
@import 'colors';

body {
  background-color: $primary-color;
}

Problem: If colors.scss is imported multiple times across different files, it could cause duplication.

Example: @ use (New way)

// colors.scss
$primary-color: blue;
$secondary-color: red;

// styles.scss
@use 'colors';

body {
  background-color: colors.$primary-color;  // Notice the namespace "colors."
}

Why is this better?

• The @use statement ensures colors.scss is only loaded once.

• Variables need to be prefixed with the file name (colors.$primary-color), preventing conflicts.

Using @use with an Alias

Instead of typing colors.$primary-color every time, we can shorten it using as:

@use 'colors' as c;

body {
  background-color: c.$primary-color;
}

Benefit: Shorter and more readable.

@use in Angular Material
Angular Material switched to @ use for theming.

Old way (@import):

@import '@angular/material';
$my-primary: mat-palette($mat-indigo);

New way (@use):

@use '@angular/material' as mat;
$my-primary: mat.define-palette(mat.$indigo-palette, 500);

Understanding @forward rule in Sass

The @ forward rule in Sass works together with @ use to organize and control access to styles.

It allows you to re-export styles from one file to another while keeping some variables, mixins, or functions private.

Before Sass introduced @ forward, using @ import meant that everything in a file was always accessible, leading to bloated styles and naming conflicts.

If you want to explicitly control which variables get exposed, you can use @forward with the show keyword.

Example: Forwarding Only Some Variables

If you only want to expose specific variables, use show:

_colors.scss

$primary-color: blue;
$secondary-color: red;
$private-color: black; // ❌ Should not be public

@forward 'colors' show $primary-color, $secondary-color;

main.scss

@use 'colors';

body {
  background-color: colors.$primary-color; // ✅ Works
  color: colors.$secondary-color;          // ✅ Works
  border: 1px solid colors.$private-color; // ❌ ERROR! Not exposed
}

If you use @ forward without show, then all public variables, mixins, and functions from that module are automatically forwarded and accessible.

Example: Forwarding Everything

_colors.scss

$primary-color: blue;
$secondary-color: red;
$private-color: black; // This is still public unless restricted

@forward 'colors'; // ✅ Everything is forwarded

main.scss

@use 'colors';

body {
  background-color: colors.$primary-color; // ✅ Works
  color: colors.$secondary-color;          // ✅ Works
  border: 1px solid colors.$private-color; // ✅ Also works
}

Since @forward is used without show, public variables, mixins, and functions from _colors.scss are available in main.scss

Conclusion

In short, @ use provides better performance, prevents conflicts, and ensures cleaner, more efficient stylesheets, making it the preferred choice for modern Sass development.

Check out my deep dives on → Gumroad