Vscode on stuartleeks.com

dotfiles tools wrappers

Sat, 27 Aug 2022 21:45:01 +0100

I’m a self-confessed fan of Visual Studio Code’s dev container experience and have a number of posts about them including a list of some of my favourite things with dev containers. I find it productive to be able to capture the pre-requisites for working with a project programmatically, and share it with others working on the project. However, there’s a feature of dev containers that I use heavily which has the potential to break this model: dotfiles.

Visual Studio Code and Dev containers in the Windows Subsystem for Linux (WSL)

Wed, 01 Apr 2020 19:18:23 +0100

UPDATE (2020-04-08): With the 1.44 release of Visual Studio Code (and the corresponding Remote Containers release), the Insiders release is no longer needed as the . I have updated the post to reflect this (update made in vscode dev container on stable release 😁).

Introduction

In my previous post I gave some thoughts on using Visual Studio Code dev containers. Until very recently your source code needed to be cloned in Windows in order to be able to build and run dev containers with Visual Studio Code. While this has still been a great experience overall, I have hit a few edge cases where being able to have my source code in Linux (under WSL) and then create a dev container from there would have been a big help.

Visual Studio Code and Dev Containers

Tue, 31 Mar 2020 20:45:01 +0100

Visual Studio Code has support for Remote Development which is a really cool feature. You can connect to another machine via SSH and work with code there (the language services etc run remotely which is the really cool part!), connect to the Windows Subsystem for Linux, or run your development environment in containers (aka dev containers). The last of these is the topic for this post.

My team has been using dev containers quite heavily for the last few months and found a lot of benefits with them. They allow you to describe your development environment with a Dockerfile and run your tools, terminal and debugger inside that container whilst keeping the editor UI local. This image from the docs shows this split:

Working With Git Rebase in Visual Studio Code

Thu, 23 Jan 2020 08:15:27 +0000

Following the git theme for mini-posts, I thought I’d give git rebase a mention this time.

When I first started working with git I found a way to pretend that it was a source control system like any other that I’d used. Eventually, I was working on a pull request for an OSS project and a maintainer asked me to rebase my changes. Now, I’d heard of rebase at that point but I hadn’t used it, so I was a bit daunted. So this post has a few tips that I wish I’d known at that point. By way of encouragement, I’ll add that getting familiar with git rebase is a huge part of the reason that I love git and has improved my developer workflow.

Setting Visual Studio Code As Your Git Editor

Wed, 22 Jan 2020 07:17:34 +0000

My last post seemed to go down quite well, so I’m going to try a few mini-posts with a ’tips-and-tricks’ theme. This works well for me as I’d started making some notes about productivity tips I use as part of my prep for an internal no-prep presentation ;-)

This one is a really small tip that is covered in the Visual Studio Code docs, but lots of people using Visual Studio Code seem to have missed it so I’m going to mention it here: you can set Visual Studio Code to be your git editor. To do this run: