Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with Deprecation Warnings in Mixins After Updating Sass #2482

Closed
beekero3242 opened this issue Jan 9, 2025 · 1 comment
Closed

Issue with Deprecation Warnings in Mixins After Updating Sass #2482

beekero3242 opened this issue Jan 9, 2025 · 1 comment

Comments

@beekero3242
Copy link

beekero3242 commented Jan 9, 2025

Description
After updating Sass to the latest version, I encountered deprecation warnings for my existing mixins due to the breaking changes described in the Mixed Declarations Documentation.

Here are the issues I'm facing:

Mixin 1: color-property
I use the following mixin to generate CSS properties dynamically. However, it triggers the warning about declarations that appear after nested rules:

@mixin color-property($component, $properties, $suffix, $color-group: '') {
  @each $property in $properties {
    #{$property}#{if($property == 'background' or $property == 'border', '-color', '')}: var(--name-#{$component}-color#{if($color-group != '', '-#{$color-group}', '')}-#{if($property == 'color', 'text', $property)}-#{$suffix});
  }
}

Deprecation Warning:

Sass's behavior for declarations that appear after nested
rules will be changing to match the behavior specified by CSS in an upcoming
version. To keep the existing behavior, move the declaration above the nested
rule. To opt into the new behavior, wrap the declaration in `& {}`.

More info: https://sass-lang.com/d/mixed-decls

   ┌──> src\styles\utils\_colors.scss
11 │       #{$property}#{if($property == 'background' or $property == 'border' , '-color', '')}: var(--name-#{$component}-color#{if($color-group != '', '-#{$color-group}', '')}-#{if($property == 'color', 'text', $property)}-#{$suffix});
   │        declaration

Mixin 2: breakpoint-media-query

@mixin breakpoint-media-query($min-breakpoint, $max-breakpoint: $min-breakpoint) {
  $min-width: breakpoint-min-width($min-breakpoint);
  $max-width: breakpoint-max-width($max-breakpoint);
  @if $max-width {
    @media screen and (min-width: breakpoint-min-width($min-breakpoint)) and (max-width: breakpoint-max-width($max-breakpoint)) {
      @content;
    }
  } @else {
    @media screen and (min-width: breakpoint-min-width($min-breakpoint)) {
      @content;
    }
  }
}

Deprecation Warning:

` ┌──> src\styles\utils\_layout.scss
34 │ ┌     @media screen and (min-width: breakpoint-min-width($min-breakpoint)) and (max-width: breakpoint-max-width($max-breakpoint)) {
35 │ │       @content;
36 │ │     }
   │ └─── nested rule
   ╵
`

Steps to Reproduce

  1. Use the mixins provided above in a Sass file.
  2. Compile the Sass code using the latest version.
  3. Observe the deprecation warnings in the terminal or build output.

Expected Behavior
The mixins should work without warnings or require minimal refactoring to align with the new behavior.

Actual Behavior
The current implementation triggers warnings, and it's unclear how to refactor the mixins to resolve the issues without changing their functionality.

The mixins are used extensively across my project, and I aim to fix the warnings without introducing breaking changes. I couldn't find a clear example in the documentation for resolving such use cases. Any guidance or recommended patterns would be appreciated.

@nex3
Copy link
Contributor

nex3 commented Jan 11, 2025

There's not a one-stop solution for ensuring the old behavior is precisely maintained. You'd have to reorder the style rules in which you include those mixins so that all the declarations and all the mixins that add declarations appear at the beginning, and all the nested rules and all the mixins that add nested rules appear after that. It's not something you can just add to the mixins themselves and keep everything as-is.

I recommend using the & {} technique to opt into the new behavior and see if it actually changes any rendering for you. It's likely that it won't, at which point you can just silence the warning until the breaking change is released.

@nex3 nex3 closed this as not planned Won't fix, can't repro, duplicate, stale Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants