@use Modules vs. @extend: Managing Placeholder Inheritance Across Boundaries

Context

Dart Sass 2.0+ deprecates @import in favor of @use with explicit namespaces. While @use prevents global namespace collisions and enables @forward for curated APIs, it introduces a hard constraint: @extend only resolves within the same module scope. A %placeholder defined in _a.scss cannot be extended from _b.scss when _a is loaded via @use.

Trade-off

Teams migrating from @import must choose between:

• Adopting @use fully and refactoring all cross-module @extend chains — often by duplicating placeholders or replacing them with mixins or CSS custom properties.
• Retaining @import (or using @use '...' as * as a shim) to preserve existing @extend behavior, accepting deprecation warnings and future removal.

Uncertainty

No automated migration path exists for cross-module @extend references. The sass-migrator tool converts syntax but cannot rewrite selector inheritance across module boundaries. Source maps and duplicate CSS output improve with @use, yet the refactoring effort for placeholder-heavy codebases remains unbounded.

What criteria should drive the decision to refactor @extend versus defer migration? Are there patterns that minimize placeholder duplication while staying within @use semantics? How do teams validate that no silent @extend failures remain after switching module systems?