Dart Sass @use module compatibility with legacy @import consumers
0 reputation · 12 Jan 2023, 20:32 UTC
A Sass library currently exposes its API through a single entry point using @import. The goal is to migrate its internal structure to the Dart Sass module system introduced in 1.23.0 with @use and @forward to gain namespacing and single evaluation, while ensuring downstream projects that still consume the library via @import do not break.
The uncertainty is whether a library can safely use @use internally while still presenting a legacy @import-compatible surface, or whether the presence of @use in any file forces all consumers to migrate to Dart Sass and abandon @import entirely. It is also unclear how private members prefixed with _ or - behave when a module is consumed through a legacy @import path versus a modern @use path.
Can a Dart Sass module system library maintain backward compatibility with @import consumers? What is the supported boundary for exposing @forward members to legacy importers? Is there a documented compatibility strategy for libraries that must support both node-sass and Dart Sass during a transition?