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

Quick answer to your questions

• Reverting the pinned Sass version and restoring the exact lockfile gives a clean rollback; the lockfile guarantees the same dependency graph, so the compiler behaves as before.
• In a mixed codebase, a file that contains both @import and @use can emit duplicate CSS if the same partial is reached twice – once via the import and once via the module. This only happens when the file is imported directly and also used as a module.
• Running sass-migrator against the old 1.8x release is safe; the tool will not apply the semantic changes that newer Sass introduces. However, you still need to review the generated CSS for duplicate rules.
• The flag that turns deprecation warnings into hard errors is --fatal-deprecation. Other flags include --no-deprecation (silence all warnings) and --quiet-deprecation (only show the first warning per file). Verify which flag your CI uses.

Rollback strategy

1. In package.json, set the Sass dependency back to the previous 1.8x version you were using (e.g., "sass": "^1.80.0").

2. Restore the corresponding lockfile (package-lock.json or yarn.lock) that was committed before the upgrade. This ensures that npm ci or yarn install --frozen-lockfile installs the exact same patch version.

3. Run npm ci (or yarn install --frozen-lockfile) to install the old compiler.

4. Execute your build command locally and confirm that no deprecation warnings appear. A quick sanity check: sass --version should show the 1.8x release.

Handling a partially migrated codebase

• Files that still use @import will compile normally with the old Sass. If you later migrate a file to @use, ensure you remove the @import line that was previously there; otherwise the same CSS will be injected twice.
• When a file contains both statements, the @import part is processed first, injecting CSS, and the @use part loads the module without side effects. If the same partial is imported elsewhere via @import, you’ll see duplicate rules in the final CSS.
• After migration, run a diff of the output CSS to spot duplicates: diff -u old.css new.css.

Running sass-migrator on the old version

# Install the old Sass locally
npm install sass@1.80.0 --save-dev

# Run migrator against the old compiler
npx sass-migrator --dry-run src/**/*.scss

Running it on the 1.8x release avoids the new deprecation logic that could otherwise rewrite imports into forwards automatically.

Deprecation flags in the pipeline

• --fatal-deprecation – turns every deprecation warning into a non‑zero exit code.
• --no-deprecation – suppresses all deprecation warnings.
• --quiet-deprecation – shows only the first warning per file.

To verify which flag your CI uses, run the exact build command locally and observe the exit status. If the command exits with a non‑zero code when warnings are present, --fatal-deprecation is active or your CI has a --strict wrapper.

What to check next

Could you confirm whether your continuous‑integration pipeline treats warnings as errors (e.g., via a --strict flag or by using --fatal-deprecation)? Knowing this will determine whether we need to disable that flag or rely on the rollback alone.