My first extension for Visual Studio Code - CSSLint

Well, it took a while, but I finally got around to writing my first extension for Visual Studio Code. As I’ve said a few times recently, VS Code is my new favorite editor now that Brackets seems to be on the back burner at Adobe. (And ok, maybe it isn’t. But VSC is faster, updated more often, and seems to have a lot more energy behind it.) I will say that the process for writing extensions for VS Code (documentation) is somewhat… complicated. To be fair, extensions for Brackets at first were a bit difficult at first too. But right now I’d say I understood about 1/2 of what I was doing when building this. It is fragile as heck so use with extreme caution. So how does it look?


In the screen shot above, you can see the green squiggles from the linting reporting on the issues. If you click the little warning icon at the bottom, you get a formal list.


As just an FYI, VS Code has internal CSS linting and they do not document how to turn this off. You can disable their linting by adding this to your preferences:

"css.validate": false

So - the code itself is a bit… intense. For linting specifically, VS Code requires you to set up a Node.js process to handle the process asynchronously. You then have to get this code into your extension code and handle keeping them in sync. The sample GitHub repo does all of this out of the box, and everything is documented, but it is really a lot to do at one time. I can say that every time I screwed up, it was because I didn’t see the “Common Questions” part at the end of doc. My strongest recommendation is that you go to the bottom of the page before you do anything and quickly check what issues they call out there. You will run into them probably.

I get why this process is complex, but it is so complex that there is no way I’d work on one while on my laptop screen. You need three instances of the VS Code open (yes, three, but again, this is for a linter, not all extensions) and managing that on a small screen would be pretty difficult. And again, to be fair, the experience of debugging a Bracket’s extension was pretty similar.

The biggest tip I can give involves logging. While you can debug the server portion of your extension, I’m a big fan of just using a crap ton of console messages. Your client code can just use console.log, but your server code can’t. However - your server code has access to a connection object that links back to the client code. That means you can do:

connection.console.log('Work or I send you to the salt mines with Notepad.exe')</pre> This will then show up in your debug console. And I kind of like that both parts of my extension can share one log. shot3 So - I did publish it to the Marketplace, and that too was a bit complex, but I think - eventually - it will show up and be available. You can find the detail page here: It is pretty bare bones though. You can find the Git repo here: Let me know what you think!
Raymond Camden's Picture

About Raymond Camden

Raymond is a developer advocate for Extend by Auth0. He focuses on serverless and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support.

Lafayette, LA