Dream of BEMifornication – or how we refactored our scss with linting

Posted on October 07, 2016 by Markus Waitl

Writing a lot of code over the years also means to deal with refactoring at some point. Your skills improve over time and technologies evolve. Coming back to an old project often makes it hard to understand what the heck Younger You was thinking when writing and structuring this code.

For example when I started learning SASS, I felt in love with nesting everything. Back then I tought nesting elements would be the best way to avoid css conflicts … I figured out that might just be true up to a certain level of nesting. When BEM came around, we started sticking to its convention, leaving previously written css code mostly untouched. Things started to get messy in our frontend codebase.

Lately my fellow co-worker Alex began to refactor our oldest project and we started talking about scss-lint. I was already using jslint in my editor but never really thought about linting my scss as well. We sat together and before long, we agreed that it is about time to start using it.

So what is scsslint?

Scss-lint is a tool to analyse your scss code for potential errors and to make sure the code conventions are respected.

In order to use scss_lint in your rails application you need to include it into your Gemfile.

# Gemfile
group :development, :test do
  gem 'scss_lint', require: false
end

Afterwards you can configure the linting rules by adding .scss_lint.yml to your applications root directory. You can find a list of all supported linting options here.

scss_files: 'app/assets/stylesheets/**/*.css.scss'

exclude: 'app/assets/stylesheets/vendor/**'

linters:
  BorderZero:
    enabled: false

  Indentation:
    severity: warning
    width: 2

  SelectorFormat:
    convention: hyphenated_BEM

A linter walks into a project

Running $ scss-lint in your terminal, will give you a good overview which files to tackle. If you want to see different information, for example the files which have no warnings, it is worth to checkout the formaters.

To use linting within your editor you need to install a plugin. I would suggest mapping linting to a key instead of automaticaly linting when opening or saving a file. If you still want to enable “autolinting”, keep in mind that it will slow down your text editor’s speed.

Jumping into the mud

I highly recommend automating most of the linting tasks: it saves a lot of time that we can spend focussing on bemifaction.

Introducing CSScomb. This is a fantastic tool for automatic linting. It formats your code very efficiently and it’s easy to customize. You can create your configuration by using the config generator on the project’s website or download some configs here. We used csscomb.json and tweaked the sort-order to match Concentric-CSS order.

I installed vim-csscomb to use csscomb within my editor but there are plugins for all major editors arround.

Let’s start digging!

Alex came up with a simple structure for our scss files:

// BLOCK
.example {
    color: #fff;
}

// MODIFIER
.example--red {
    color: #ff0;
}

// ELEMENT
.example__title {
    font-size: 1.5rem;
}

Dividing our modules in BEM-blocks ensures the usage of only one block element per file. Bemify your classes, refactor your views, run CSScomb.

Voilà.

Conclusion

It can be a long road and in the beginning it seems like a hole with no bottom. But seeing the warning and error messages disappear can be very rewarding. Is it fun? No. Do you end up with cleaner code, better maintainablity and less conflicts in your stylesheets? Yes.

Dream of BEMifornication – or how we refactored our scss with linting

So what is scsslint?

A linter walks into a project

Jumping into the mud

Conclusion

Related Posts