Sass 1.77.7 Breaking Change: Mixed Declarations - Are there any simple work arounds or updates for existing projects?

Question

Sass announced there will be some upcoming breaking changes to the syntax in mixed declarations. As of Sass 1.77.7 I'm getting the following warnings when compiling. -

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 & {}.

Below is a basic example of the issue. If we define a mixin and then add it to a style class at the top of the class then declare other rules we will receive the above warning in the console.

@mixin border($color) {
    border: 1px solid $color;
}


.style-with-mixin {
    @include border(red);
    padding: 20px;
    // ...Any other styles
}

To remove this error we either have to wrap styles like the following -

.style-with-mixin {
    @include border(red);

    &{
        padding: 20px;
        // ...Any other styles
    }
}

Or shift the mixin to be the last style declaration -

.style-with-mixin {
    padding: 20px;
    // ...Any other styles
    @include border(red);
}

However, both of these solutions involve a lot of rewriting of styles for whole projects which isn't going to be realistic for me. Other than locking the sass version has anyone been able to find a work around that can be implemented efficiently in exisiting projects?

Gurolinick

Answer 1

there is no need to add &{} everywhere just reorder your lines make sure props at beginning then the nesting selectors

example this

.main{
   .content{
     color: green;
   }
   font-size: 1em;
}

should be

.main{
   font-size: 1em;
   .content{
     color: green;
   }
}

Pita

Hi Jasim, thanks for the answer. I have added some more details to better highlight the issue. I'm trying to avoid having to go through entire projects and reorder styles. For existing projects it's just going to be too time consuming and clients aren't likely going to be willing to pay for it. – Gurolinick

For me the main problem is the usage of mixins. In your example, I could add a mixin that has props and also selectors inside. That results in an warning, because the order is not completely correct because of the mixin. Do you know how to handle that? – Pilotage

Answer 2

Not exactly for this question for converting large codebases, but i have some tricks how to handle code that would be become unreadable with the changes.

We introduced two mixins that do the same, but with different semantics. The main point of these is to get rid of parent selectors (&{}) without context to make the code more readable.

@mixin override-after-nesting {
    & {
        @content;
    }
}

@mixin nest-to-avoid-collision {
    & {
        @content;
    }
}

Those are for two different problems:

1. I might have a mixin that nests some declarations, but I want to override a declaration inside the mixin afterwards.

@mixin bar {
  background: red;
}

.foo {
  @include bar;
  & {             // instead use @include override-after-nesting
    background: blue;  
  }
}

2. When using two mixins that have nested and unnested declarations you can't oder them correctly, because the nesting of the first mixin will always stand before the unnested declarations of the second mixin.

@mixin foo {
  & {       // instead use @include nest-to-avoid-collision
    background: red;
    .class2 {
      color: blue;
    }
  }
}

@mixin bar {
  & {       // instead use @include nest-to-avoid-collision
    padding: 10px;
    .class2 {
      margin: 10px;
    }
  }
}

.class1 {
  @include foo;
  @include bar;
}

Herwig

Answer 3

The problem is even worse when you have mixins that also use nested rules inside. I have no clue how to fix the deprecations then without having multiple selector duplicates in my output css.

Hardly

Answer 4

I also have some mixins with nesting inside of them. i.e. I have a headline mixin, which I'm using as a base styling for every headline on the page. It includes the normal mobile styling and then a media-query for the desktop behavior.

I include the mixin first and then i might have to override some properties on it. So do I have to split up the mixin into "headline-mobile" and "headline-desktop" to be able to include it in the correct order?

This change is not really thought through by the sass team...

Humpbacked