Today, Sass uses complex heuristics to figure out whether a / should be treated as division or a separator. Even then, as a separator it just produces an unquoted string that’s difficult to inspect from within Sass.

I am finally getting usable source maps for SCSS, wow!

Sass variables, like all Sass identifiers, treat hyphens and underscores as identical. This means that $font-size and $font_size both refer to the same variable. This is a historical holdover from the very early days of Sass, when it only allowed underscores in identifier names. Once Sass added support for hyphens to match CSS’s syntax, the two were made equivalent to make migration easier.

Sass

node-sass may be faster than dart-sass, but as of writing this dart-sass is the only library which implements the @use rule, which is strongly recommended over @import. According to the official sass-lang website:

@import url() is a runtime CSS statement, not a Sass @import module.

To bundle this in your own code, use a Sass processor (not a Sass Svelte preprocessor, but a Sass processor)

After a few hours experimenting (updated NPM, NODE, ...) I found that renaming _smui-theme.scss to smui-theme.scss (without underscore prefix) solved the problem. I don't understand the mechanics behind (why in documentation is file with prefix).

Dart Sass has replaced Ruby Sass as the canonical implementation of the Sass language.

Sass makes CSS fun again.

Dart Sass is the primary implementation of Sass, which means it gets new features before any other implementation. It’s fast, easy to install, and it compiles to pure JavaScript which makes it easy to integrate into modern web development workflows.

The rule is written @forward "<url>". It loads the module at the given URL just like @use, but it makes the public members of the loaded module available to users of your module as though they were defined directly in your module. Those members aren’t available in your module, though—if you want that, you’ll need to write a @use rule as well.

Using as * adds a module to the root namespace, so no prefix is required, but those members are still locally scoped to the current document.

Internal Sass features have also moved into the module system, so we have complete control over the global namespace.

The file is only imported once, no matter how many times you @use it in a project.

The new @use is similar to @import. but has some notable differences:

In brief, @import is being replaced with more explicit @use and @forward rules. Over the next few years Sass @import will be deprecated, and then removed.

When you use a function like color(). it’s impossible to know exactly where it was defined. Which @import does it come from?

What a very strange design decision - to treat the files as the same.

We’ve written a migration tool that automatically converts most @import-based code to @use-based code in a flash.

The @import rule has a number of serious issues:

To share variables between Sass files, you can use Sass imports. For example, src/App.scss and other component style files could include @import "./shared.scss"; with variable definitions

percentage(5/7);

This is a perfect use-case for @extend. These rulesets are inherently related; their shared traits are shared for a reason, not coincidentally. Further, we aren’t transplanting their selectors hundreds of lines away from their source, so our Specificity Graph stays nice and sane

n the Webpack approach, each Sass file is compiled in isolation. This isn't a new idea, but I think it's a much better way of doing Sass. It just means you need to @import dependencies like variables & mixins wherever you use them