I’m very excited to have written my first Visual Studio Extension. Prior to this, my team and I heavily relied on Web Essentials 2013. It was somewhat clunky: it compiles simple Sass files very well. However, we kept running into a few issues:

• It wasn’t always up to date with the latest version of Sass, making it difficult to use mixin libraries like Bourbon. I know this wasn’t Web Essential’s fault: the node-based tools were out of date.
• Bad error messages. Sometimes the errors were false-positives, the files would compile just fine, but tell us there was a syntax error (with no additional message).
• Sometimes it could get into a state where it wouldn’t compile Sass files at all anymore until Visual Studio was restarted.
• It supported Sass partials (files that start with an underscore), but sometimes you had to focus a Sass file that imported the partial in order to kick it off.

So it was a little buggy but we could get by and produce some very-maintainable CSS after realizing we could ignore any sort of error messages and just restart Visual Studio if it didn’t work at all. Despite these issues, it provided a massive benefit: all any team member had to do was install the extension and that was it. They were immediately Sass-compatible. No additional tools, installations, or configuring. Create a .scss file and you’re off in running.

Then came the day Mads Kristensen announced that all node.js-based tools (Sass and LESS compilers) were removed from Web Essentials. I asked via Twitter what the recommended replacement was.

@SamRueby Grunt or Gulp. I won’t use WE for it since it’s no longer there in WE2015

— Mads Kristensen (@mkristensen) January 12, 2015

He recommends using a JavaScript Task Runner. I agree that does seem to be a solution, but now using Sass isn’t simple anymore. It’s not create a .scss and you’re done. Configuring Grunt/Gulp is not trivial. It’s also not going to be trivial when the rest of my team is not familiar with Grunt/Gulp and needs to make a change. Worse, not everyone is convinced yet this is the way to go.

Another alternative is to use Ruby Sass. That’s not too bad. It does require installing Ruby, and then the Sass gem, which are extra steps. After that, you need an easy way to run the command line to have Sass starting listening, which will definitely not be automatic. I wanted to have the simplicity I had before. “Install this extension and you’re ready.”

CompileSass was born.

I wrote the cleverly-named CompileSass Visual Studio extension and added it to the Visual Studio Extension Gallery. Right now this plugin features:

• Compiles fast. The plugin is backed by LibSass and its .NET port.
• Supports Sass partials. That’s those Sass files that start with an underscore that are just meant to be injected into other files.
• Displays output to the Build Window, showing a success message or an error message with file name and line number.
• Supports Visual Studio 2013 and Visual Studio 2015 CTP.

Try it out and let me know how it goes for you!