Dart Sass @import deprecation: how should a mixed @import/@use codebase sequence its migration?

Migration sequencing during the @import deprecation window

Dart Sass now emits deprecation warnings for @import (starting around the 1.80 release line) while still compiling it, and the documented replacement is the module system built on @use and @forward. The goal is to migrate a large stylesheet codebase to the module system without breaking builds mid-transition.

The constraint is that partial migration is risky. The Sass documentation warns that loading the same file through both @import and @use can produce duplicate CSS output, and @import ignores the leading-underscore/hyphen privacy convention that module files may rely on. The sass-migrator module migration automates the rewrite but is documented as potentially needing manual fixes for complex import graphs and global dependencies.

Assume current Dart Sass; exact warning text, silencing flags such as quietDeps/silenceDeprecations, and the removal timeline should be verified against the installed version.

1. Should migration proceed leaf-files-first or entry-points-first to minimize the window where a file is loaded both ways?
2. Is it safer to run sass-migrator across the whole repo at once, or migrate per feature folder given the duplicate-CSS risk?
3. How should global configuration (e.g., variables previously set via import order) be restructured under @use ... with () before deleting any @import?