Rolling back a Dart Sass upgrade after @import deprecation warnings broke the build

A project currently compiles with Dart Sass and relies heavily on the legacy @import rule across many partials. Since the 1.80.x line formally deprecated @import in favor of @use/@forward, upgrading to a newer release floods the build with deprecation warnings, and the pipeline may treat warnings as fatal depending on its flags.

The goal is a safe upgrade-and-recovery strategy: move to a current Dart Sass version while keeping a reliable way back if compilation output or behavior changes unexpectedly. Constraints: the codebase is not yet migrated with sass-migrator, some partials depend on @import's global namespace, and the build tool pins Sass via package.json plus a committed lockfile. Sass itself has no built-in downgrade mechanism, so recovery presumably means reverting the pinned version and lockfile together.

Assuming Dart Sass in the 1.8x range, the open questions are:

• Is reverting the pinned version and lockfile sufficient for a clean rollback, or can a partially migrated codebase (mixed @import/@use) produce duplicate CSS that survives the downgrade?
• Should the sass-migrator run be decoupled from the version bump entirely, and does running it on the old version avoid the semantic changes flagged in its documentation?
• Which deprecation-related flags (e.g. --fatal-deprecation) determine whether warnings become hard errors, and how can that be verified per build pipeline?