I found that warnings from ActiveAdmin's stylesheets can be silenced using the quietDeps option.

https://sass-lang.com/documentation/breaking-changes/color-functions/#silencing-deprecations-in-dependencies

I use Vite, so I accomplished this by modifying my vite.config.ts as follows:

--- vite.config.ts
+++ vite.config.ts
@@ -4,6 +4,13 @@ import sassGlobImports from "vite-plugin-sass-glob-import";
 import StimulusHMR from "vite-plugin-stimulus-hmr";
 
 export default defineConfig({
+  css: {
+    preprocessorOptions: {
+      scss: {
+        quietDeps: true,
+      },
+    },
+  },
   plugins: [
     ViteRails({ envVars: { RAILS_ENV: "development" } }),
     sassGlobImports(),

@mattbrictson I think it would be best to resolve this by not using the lighten or darken functions and avoiding @use as well for compatibility. The values should be defined in a variable the user can set and change. What do you think about adding new variables to replace those and adding a conditional where if the variable is undefined to print a warning explaining that it should be set? This would make it compatible with both sassc and dartsass and would resolve the deprecation warning. It would benefit others as they transition to dartsass while on v3. Would you like to contribute that update?

@javierjulio Hmm. I would rather not introduce more warnings. Is it fair to say that users who have already migrated to dart-sass are likely going to be adopters of v4, as well? Whereas users sticking with v3 are likely also going to be using older tech like sassc?

In which case I think keeping the experienced unchanged for v3 users is probably for the best. Users like me who are trying to make v3 work with dart-sass can be expected to have to put in some extra effort and/or deal with warnings.

So maybe we can extract new variables like you are suggesting, but still use the sassc lighten/darken functions for full backwards compatibility, like this:

$primary-gradient-start: lighten($primary-color, 5%) !default;
$primary-gradient-stop: darken($primary-color, 7%) !default;

And then in the documentation, we can tell users of dart-sass that they will need to manually define these variables to avoid deprecation warnings. If they define the variables themselves, then the lighten/darken functions will be skipped, due to the fact that !default variable assignments are skipped if the variable already has a value.

What do you think?

@mattbrictson I think that's great. Thank you. I agree, I wouldn't want more deprecation warnings but my thinking was to just notify users affected so they know what to do to resolve it. Calling it out in the changelog instead would help as a non-warning alternative.

But what I didn't know is what you mentioned about !default variable assignments as I figured if it still contained deprecated code that it would warn. If you know that it will not emit any warning on Dart Sass for that case, I agree that's best. Please feel free to open a PR so that can be fixed for you and others. We'll cut another v3 release.

Do you know of any other Dart Sass warnings currently being emitted on ActiveAdmin v3 with the latest? I'm hopeful it's only the @import deprecation (source) which won't be removed anyway in v2. As they suggest it would be best to just ignore that warning.

@javierjulio here is the test I did:

$primary-color: #5E6469 !default;

// Explicit assignment causes the subsequent default assignment to be skipped
$primary-gradient-start: #6a7176;

// No deprecation warning triggered since the assignment is skipped
$primary-gradient-start: lighten($primary-color, 5%) !default;

body {
  color: $primary-gradient-start;
}

Using the latest dart-sass (sass@1.80.6 Node package), there are no warnings. So it seems like this approach will work.

Unfortunately, I don't have much bandwidth to contribute a PR right now, but I will try to come back to this later.