Fixing CSS Stylelint Errors Generated By SASS [A How-To Guide]

So you’ve started using sass, it makes things easy, right? Well, true, but one day, I run into some errors that almost changed my mind about that.

Before we get into it, for those who don’t know, SASS, it stands for Syntactically Awesome Style Sheets and everything you need to know about it is clearly expressed in their tagline, “CSS with superpowers”.

It allows you to do stuff like nesting selectors, creating loops and functions and other fun stuff you wish you could do with CSS.

I had been experimenting with it for some time but I hadn’t actually used it to work on a real project and all was good until I did and when I thought I was about to get done with my project, which I almost completed in record time by the way(thanks to sass), then I run stylelint and that’s when I got introduced to a whole new different side of sass I never knew existed.

If you’re wondering, Stylelint, is just that, “A style linter” for your CSS. A lint, or linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. So, Stylelint is just one of many other types of linters out there…and yeah, even sass has linters one of which is…you guessed it, sass-lint.

Now don’t get me wrong. These errors are not unique to sass. These are normal linter errors. Infact, most of them are very easy to fix if you’re using vanilla(pure) css, the complexity comes in with sass as I will explain below.

Here is a full list of all the errors I came across:

Expected selector [selector] to come before selector [selector].
Unexpected Duplicate [selector or property].
Expected Indentation of [number] of spaces.
Expected newline after “,”.
Unexpected white space at end of line.
Expected empty line before rule.
Unexpected missing generic font family.
Expected white space after “)”.
Unexpected missing end-of-source newline.
Expected no more than 1 empty line.

Most of these errors are self-explanatory and the reason you’re unable to see most of them in the image above is that I added the option “--fix” in the stylelint command. The “fix” option enables stylelint to fix everything it can for you automatically and it leaves what it can’t for you to fix manually.

Now with sass! it’s not that easy. Unless of course, you’re completely sure that you’re done with your project and will not use sass ever again on that particular project, then you can just stop compiling sass and put all the sass files in .gitignore, or even just delete them.

Then, from there you can correct the existing errors in your CSS files directly and call it a day. But if you intend to continue using sass on those same files on that project at any point in the future…then you have to fix those errors through the sass files.

Keep in mind, while using sass, you’re not supposed to change anything in the css files compiled by sass because as soon as you compile sass again, all the changes you will have made will be lost. Take it like this. Don’t touch those css files compiled by sass. Its a waste of time. Nothing you write there will stick for as long as you’re still using sass to compile your css.

Finding and fixing the errors in your css files from your sass files is not straight forward because the error message points you to the error in your css file but remember you can’t edit your css files directly.

So you’re supposed to go to the sass file that compiled the css file with errors and try to pin point the origin of the error. For instance, for an error in a file named main.css you go to main.scss to find and fix the error.

Let’s checkout some of the errors that i encountered:

Expected selector [selector] to come before selector [selector] — This error run circles around me while I searched for solutions online to no avail. So I ended up right where I started staring at the errors in my editor’s terminal with a blank face not knowing where to even start.

Many tweaks and consultations later, I found out only two things that were able to work for me. “You either avoid nesting your selectors” (which defeats the whole purpose of using sass) or “you give all your elements class names if you do” (read about BEM ).

I know, the error tells you that it expected this selector before that selector, so you might be wondering, why don’t we just switch them, right? well, if it was vanilla css, sure, why not? but with sass, nesting HTML tags as css selectors (instead of classes) gets in the way.

I too tried to move things around but then I soon realized I was moving in circles…solving one of these errors caused another one of these same errors.

Unexpected Duplicate [selector or property] — This one comes up when it identifies duplicate selectors or duplicate properties under one selector in your css file. For example…

In the file /main.scss
@mixin bg-img{
  background: {
    image: url("../image");
    size: cover;
    position: center;
  }
}
.header {
  @include bg-img; // Say you want to override the background-size property in the mixin, and you put it after the @include statement.
  
  background-size: 80%;
}

This will be compiled into….

In the file /main.css
.header {
  background-image: url("../image");
  background-size: cover;
  background-position: center;
  background-size: 80%;
}

When you run stylelint, it will flag this as a duplicate property.

Sass has this concept of “partials” it works well with the concept of “7–1 architecture/pattern”. Well I won’t get into them but all you need to know is that they help you make your code more modular. Which basically means breaking up your code into smaller chunks which are easier to maintain and scale.

Well, the thing is, when you divide your code up, into different parts like layout, components, themes, pages etc. chances are that you will use a specific selector in most of these files. And when that happens, you will find yourself with something like:

In the file /main.css
//from one partial
.header {
  Display: flex;
  flex-direction: column;
}
somewhere in your css file after 100 lines of code
//from another partial
.header {
  background-color: red;
}

When you run stylelint, it will flag this as a duplicate selector because remember, all your partials are compiled into one css file. So to fix this, you end up deleting the selector (for instance .header) from one partial and transferring whatever was in it into another. So that when sass compiles it, it shows up as one selector in your css which messes with your modularization plans quite a bit.

All the other errors have little or nothing to do with sass and most of them can be fixed easily by adding a “--fix” option in the stylelint command. So I won’t get into them all.

I also run stylelint on my sass files and this popped up….

Of course, I run it with the “--fix” option and it weeded out most errors and it left me with these.

Now, these errors are basically saying that certain sass at-rules like “@include” and “@mixin” are unknown to stylelint. Although stylelint partially works for sass files with a .scss file extension, stylelint is meant for CSS.

So to solve these issues I would have to edit my stylelint configuration file and tell it to ignore those specific at-rules but seeing as how it wouldn’t have any further impact on my css files, I decided these errors weren’t worth the trouble. So I got rid of them by adding all my sass files to my .gitignore file and that did the trick.

The reason I run stylelint on my sass files was that I use Stickler, which basically runs linter checks on your remote Github repository. It uses the rules defined in the linter configuration files in your project to basically do the same checks you would normally do with stylelint.

Except, while you can choose on which files to run stylelint locally, stickler on the other hand checks all your style files which would include your sass files.

It kicks in when you’re trying to make a github pull request and runs all the necessary linter checks and informs you of any errors if they exist before you merge your code.

Now, this is why I run stylelint on my sass files, and why I later added them to my .gitignore file, otherwise those same errors you saw in the last image above would again be flagged by stickler if I had tried to create a pull request to merge my code.

Conclusion

Sass is great and very useful, it makes life easy for the developer. I can’t imagine coding any other way now that I've been infected by its charms.

I run into an unexpected wall which almost changed my mind about sass and when i overcame it, I felt I should share in case anyone else gets stuck. God knows I have benefited a lot from other people’s articles.

Speaking of which, this technique described in BEM and SASS: A Perfect Match by Andy Barnes will go along way to future proof you from annoying errors and will also come in handy when maintaining or scaling your code.