Implementing the Sass Module System with @use and @forward
Stop using @import in Sass. Learn how to use @use and @forward to implement namespacing, prevent global variable collisions, and build maintainable design systems.
Loading…
ReadMeFeed / Community knowledge
#dart-sass
Real questions. Useful conversations. Find the people who know your stack.
sassSolving Namespace Collision: Moving from @import to the Sass Module System
Stop fighting global namespace collisions in Sass. Learn how to use @use and @forward to encapsulate styles, eliminate duplicate CSS, and build a scalable UI library entry point.
Can Dart Sass 2.0's async-only importers/functions be used in low-traffic projects without increasing build complexity?
Background Dart Sass 2.0 removed the legacy synchronous JavaScript API, requiring custom importers and functions to use the async-only API. This forces projects with custom Sass logic to adopt async compilation patterns, even for simple use cases. For low-traffic projects, the primary cost is developer time spent refactoring build tooling rather than computa
Does Dart Sass require explicit --embed-sources to include source content in source maps?
Goal: Determine whether the default source‑map behavior in Dart Sass (≥1.23) provides a reliable way to back up and verify recovered Sass source after CSS compilation. Constraint: With the default configuration the embedSources flag is false, so generated .css.map files reference external .scss files rather than embedding their content. Verification therefor
Sass @use Namespace Limits: CSS Custom Properties Stay Outside Module Scope
Since Dart Sass 1.23, the @use rule loads stylesheets as namespaced modules, and Sass variables like $primary can be referenced through an alias such as t.$primary . The documented behavior for CSS custom properties is different: declarations like --primary are plain CSS rather than Sass variables, so they are not exposed through a module namespace and are n
Dart Sass and LibSass in one codebase: can @use modules and slash division coexist safely?
Context A shared style library is consumed by two build pipelines: one compiles with Dart Sass (the sass npm package), the other still runs a LibSass-based compiler. Core syntax like variables, nesting, and mixins is expected to match because both implementations historically followed the same sass-spec suite, but the module system and division behavior are