My VS Code Daily Helpers

There’s a lot that I want to write about, and now it is Dry January, I might actually start (or finish) writing some of the ideas in my head. And I wanted to start with my VS Code daily helpers.

Maybe all of this little tips are old hat, but I’m hoping something will help someone, and equally desired, perhaps there is a daily helper or two out there that I might not be aware of – I’m certain there will be, but whether anyone adds a comment is another matter!

I’m not going to cover things like ESLint, Prettier or Co-Pilot – partly they seem too obvious to cover, also they have been covered elsewhere to a great extent and each would be better with their own blog post, containing set-up details, how to use, etc.

These are just the little tips that help me be slightly more productive in my role.

Bracket Pair Colourisation

Yeah, I’m writing in UK English. Apparently this is enabled by default nowadays – but I definitely had an extension for this once.

Oh well, moving on. Great start to the post, James.

Pretty TypeScript Errors

Don’t you just love TypeScript errors?

My example here is relatively straight-forward to figure out – in my day-to-day role I come across some pretty horrid TypeScript warnings, though I’m wary of sharing my employer’s code (except via Co-Pilot, of course).

Yet it still isn’t very easy to read, which is where the extension, Pretty TypeScript Errors comes in handy:

Your mileage may vary, but I find this easier to read, and therefore fix, with the object laid out vertically, and a clear breaking change labelled – “property breakTypeScriptForFun does not exist on type IntrinsicAttributes & HeroPostProps”.

Though by time I finish writing this post, it will probably be a default setting in VS Code. It would be nice if there was a way to increase the size of the error overlay, but I’ve not worked it out.

Jest Runner

This one I’m going to have to use a work example, because I don’t have any unit tests on my personal projects. BAD HUMAN. I really should, given that I’m far more accomplished at writing code than writing tests – why am I not spending my spare time writing unit tests? Possibly because it’s more fun to build things I can see. Anyway, I digress (I do this a lot when writing).

Previously when I used Mocha/Chai there was an easy way to run one single unit test (please don’t ask me to remember the command). But when we moved over to the new tech stack at M&S, using Jest as the testing framework, I could not find any command that would run just one unit test, on our set-up. And we have 2,000+ unit tests on the app I mostly work on, which takes around 10 minutes to run and uses almost all of my Macbook’s resources.

Step in Jest Runner, an extension which adds a little “run” button above each unit test, and each describe block – and does exactly what I want. Phew.

Indent Rainbow

To me, Indent Rainbow is most useful when I’m editing complex JSON objects or maybe when coding with something that I’m not set-up for so well, like PHP/WordPress:

Those faintly coloured lines occasionally help me keep my code on track. Also…don’t judge my Lighthouse budget. Thanks.

Code Spell Checker

Gosh I always feel so bad when I code review for non-native English speakers and have to correct them on their English. Imagine that you’ve got a 500 line PR in review, got your first approval, ready to go, then the second reviewer goes “allways should be spelt always – please can you correct”. And I will say it, because if I was writing in Spanish, I’d like to think that my Spanish colleagues would correct me. Plus standards too.

But still, it’s frustrating. Enter Code Spell Checker.

My English language skill is pretty good – maybe very good but I don’t really like to blow my own trumpet. Yet even I use it…and if I write a variable name using a word that Code Spell Checker doesn’t recognise, it adds a little wiggly underline.

Quick Fix

I assume plenty of people know this, but in built in VS Code, when you hover over the nasty red wiggly line, it often gives you options for a Quick Fix.

In this case, it is offering to correct my spelling to the component called StyledLink, when I click on Quick Fix:

What I use it for most, is to import files/components for me – that is assuming that I didn’t use a shortcut to import when writing PostHeaderProps in the first place.

Refactor

This is something in VS Code which I don’t think I’m getting the most out of yet, but if you highlight some code and right-click, you’ll see refactoring options.

For example, I’m re-writing my personal blog to be in NextJS/React – this current file has 450+ lines, more than half of which are taken up by styling of the inspiringly-named Block component. Cue VS Code’s Refactor to the rescue:

Move to a new file, you say?

What a good idea. And it does it for me – no need to create a new file, do any fiddly copy and paste stuff – and it makes sure you’ve exported/imported correctly, etc. You might want to change the file name though – I’ve had it decide to do things like Block1.tsx.

Block is now in it’s own component, and being imported to the file where I was originally using it.

The other thing I use it for sometimes is to create functions out of existing code.

For example, maybe this should be in a function so I can re-use it elsewhere in the file/codebase:

A right-click to get the Refactor option, and a left-click to choose my style of function, and this code is now in a function created in the same module – it even had a crack at the types, albeit it decided on “any” for the sheetID.

I’m done

OK, this blog post is long enough, but hopefully someone somewhere took a useful tip from it – and maybe you even have one or two for me. I’d like to think the comments functionality still works after I migrated the site to a new host, which was exactly the sort of weekend job I was hoping for in 2024.

Enjoy writing code!