Eugene Onegin and Vladimir Lensky’s duel - Ilya Repin

A Less to Sass migration

As a UX Engineer at Thoughtspot and manager of Radiant (the company’s design system), one of my goals is to improve the code base of our product and especially the CSS: I’m focusing on getting visual consistency across the board (243 unique colors!) but also trying to improve the scalability and robustness of our code.

After an audit, I found out that the CSS (344 files) was written in Less with a ton of technical debt, so while I was trying to refactor everything, I’ve advocated in favor of switching from Less to Sass.

Why change?

While Less and Sass offer very similar functionalities, I prefer Sass because:
- Sass has a bigger community to rely on, especially in the context of design systems (if you don’t believe me, have a look at Adele, a repository of publicly available design systems and pattern libraries). That means good examples for inspiration and plenty of people to answer your questions.
- it’s also apparently vastly endorsed by front-end developers (see this 2018 poll). You might not care about it but it comes into play when you’re hiring…
- I also find its syntax less error-prone (no pun intended!).

Let me show you an example:

.amiaselector {
  color: red;
}
...
.amiamixin {
  .amiaselector;
}

This is an oversimplified Less file and it’s perfectly correct to write it this way. Yes, you could be a bit more verbose and achieve greater clarity on what’s happening, but when you get to refactor hundreds of files with this type of code you can’t tell for sure just by reading it that amiaselector is a class used anywhere in your HTML or a mixin. And, if it’s the latter, it will still get exported in your compiled CSS because of the lack of parentheses at the end of its definition.

OK, so how did I do it?

There are several packages that you can use to convert Less to Sass files. After testing a few, I ended up using this one. In the end, there’s no magic here: clever regex will work best if the original code is written in the purest syntax form. And again, no software will be smart enough to know if a Less mixin is also used as a class selector in your HTML markup.

Looking at it a bit more deeply, there were actually 2 kinds of Less files in my code base (and probably in yours, too):
- files where mixins and variables were defined
- component files where those mixins and variables were applied
The first ones need more attention, but they’re also most likely the fewer (around 30 in my case). To deal with them, I ended up using online compilers to make sure that the output was the same in Less and in Sass.
The second ones were simpler, but also more mundane.

In the end, I did a first pass on the 344 files in 3 days of work.

Of course, after that there was still a lot of compilation error that I needed to deal with. You can count another day or two to fix those.

Some obstacles that I encountered in my journey

1. Less doesn’t care if you declare a mixin after invoking it. Sass needs it first.
   You might prefer the flexibility of Less in this case, but personally I think it’s a better practice for Sass (JavaScript hoisting anyone?).
2. In Less you can invoke !important at the end of a mixin declaration and it will be added at the end of every CSS property included in the mixin.
   I’ll let you judge the value of this feature, depending on how you treat !important in your CSS (hint: you should probably avoid it).
3. I found Less mixins in the source code that were multiplied to address the case if you had 1 to n arguments.
   Ex: .mymixin (@firstarg){} .mymixin(@firstarg; @secondarg){}, etc.
   You can have just one mixin in Sass with optional arguments.

In conclusion

If you want to go down the same path, know that it’s doable but not a particularly enjoyable stroll, and highly dependent on the quality of the source code. If you want to change just for the sake of change, I wouldn’t recommend it.

In my case, this is just the first step into an effort to refactor and optimize the source code and establish a design system, so if I were to do it again, I certainly would, especially since it didn’t take as long as I feared.

Good luck and don’t hesitate to reach out to me if you have any questions!