Write code anywhere with Codespaces

The dream of anyone who works with technology is to always be with their best friend, their computer. There are plenty of solutions out there that turn small devices like Raspberry Pis into full computers, and others that build tiny pocket computers you can access at any moment.

There are several reasons someone might need, or simply enjoy, having a computer by their side at all times. A lot of the time, people just want a super powerful tool within reach for whatever comes up, or even to build out that idea they had in the middle of the street. In other, more special cases, the person might be a maintainer of critical projects and needs to always be ready to fix whatever breaks, which takes away their freedom to move around. Having a device like this gives that person their mobility back.

We can have the best portable machines in the world, but no computer matches our own, with our environments and our own settings.

Codespaces#

Recently, at its Satellite 2020 event, GitHub launched a new feature on the platform: Codespaces. Right now, it’s only available if you request early access through the website. But you might already be one of the people who recently got access and can enjoy this incredible feature!

For now, GitHub Codespaces is in beta and you might not have the feature enabled. So you won’t be able to see what I’ll show next, but you can sign up directly on the site for early access.

Codespaces are an online implementation of Visual Studio Code. Since it’s an editor built on web technologies, VSCode has the incredible advantage of being one of the few projects that can be ported across platforms extremely easily.

This had already been done before with Code Server, we even used an interesting implementation built by Alejandro Oviedo, our colleague from Argentina, at Nodeschool SP, but one of the big problems with Code Server was that its extension store didn’t support every existing VSCode extension, and the editor also got confused when using keyboards with different layouts.

The big advantage GitHub Codespaces (GH Codespaces, or GHC) brought is that it’s integrated directly into GitHub, meaning you can open any repository you have write access to in a ready-to-go web editor! Here’s an example from my GotQL repository:

GitHub repository clone screen showing the "Open with Codespaces" button

And all of this is free, for both paid and private repositories.

How it works#

Codespaces are built on top of another existing Microsoft solution called Visual Studio Codespaces (VSC), which is an excellent paid alternative to GH Codespaces if you’re looking for something more open, because VS Codespaces spin up a virtual machine on Azure and connect to it through VSCode’s native feature called Remote Development.

Remote Development connects to another computer running a small server on the other end. In other words, you can split the editor’s processing from its interface. This way you can run VSCode pretty much anywhere, because any browser that supports modern JavaScript can run the editor’s interface.

And then we combine another amazing piece of technology: containers. As you may have already seen right here on the blog, containers are an incredible technology that lets you run pretty much any application in a self-contained way, without depending on external libraries. Codespaces take a lot of advantage of this, mainly so they can build the images for the machines that will run them.

This way, we can have a container holding every tool our project needs to run, because it’s fully customizable.

Visual Studio Codespaces#

Before we dive into GitHub Codespaces, let me show you how we can use VS Codespaces to create a remote development environment, so we can understand what we’re dealing with.

After logging in and creating your VSC instance, let’s create a new codespace:

Create button for a Visual Studio Codespace

And, after clicking the “Create Codespace” button, things start getting interesting, because we get a series of great options we can turn on:

Options screen for Visual Studio Codespaces

The first option is pretty simple, we have to give our codespace a name, the name we’ll use to identify that machine, so it needs to be pretty descriptive.

Next, we get the more interesting option: VSC itself already lets us start a codespace from another GitHub repository, meaning GH Codespaces itself is just a different interface for VSCs.

From there we get to configure our VMs, so we can choose how powerful our remote machine will be and also how much idle time it can have before it suspends itself to save costs.

And then we get to the coolest part! We can set what’s called dotfiles, the configuration files for our shell. This way, we can have a separate dotfiles repository, like I do, plus a script that installs those dotfiles on our online machine. In other words, we can replicate exactly what we have on our local computer inside a web interface!

GitHub Codespaces#

With GHC it’s exactly the same thing! The only different action you’ll need to take is going into a repository, like GotQL, clicking the green “clone” button, then clicking “open with codespace”:

Every beta user gets 2 free codespaces. That means you can keep up to 2 development machines without paying a single cent. After that, you’ll need to remove the old ones to create new ones. In the GotQL example, we have the option to open with Codespaces, and this action alone will already create an environment that’s ready for development, with every dependency installed.

But how do we actually do this?

Customization#

One of the coolest features of codespaces is that they’re fully customizable.

For dotfiles, you can either configure your local VSCode (the editor installed on your machine) to pull a set of files as this documentation explains, or, in GitHub’s case, you can have a repository directly named dotfiles, as GitHub’s documentation explains.

But you can do even more than that with a folder called .devcontainer. What this folder does is group together the possible configurations for a codespace. Inside it we can have a Dockerfile, a file called devcontainer.json, and an sh file that sets up our environment’s shell. When we create a codespace from a repository, GitHub will look for this folder in the repository and build the codespace based on it.

Let’s look at the .devcontainer example from GotQL. We have a Dockerfile, which is responsible for saying what kind of container, or what kind of environment we’re going to have, it’s where we’ll install packages, create users, and so on, as well as choosing our base operating system image.

1
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:14
2

3
# The javascript-node image includes a non-root node user with sudo access. Use
4
# the "remoteUser" property in devcontainer.json to use it. On Linux, the container
5
# user's GID/UIDs will be updated to match your local UID/GID when using the image
6
# or dockerFile property. Update USER_UID/USER_GID below if you are using the
7
# dockerComposeFile property or want the image itself to start with different ID
8
# values. See https://aka.ms/vscode-remote/containers/non-root-user for details.
9
ARG USERNAME=node
10
ARG USER_UID=1000
11
ARG USER_GID=$USER_UID
12

13
# Alter node user as needed, install tslint, typescript. eslint is installed by javascript image
14
RUN if [ "$USER_GID" != "1000" ] || [ "$USER_UID" != "1000" ]; then \
15
        groupmod --gid $USER_GID $USERNAME \
16
        && usermod --uid $USER_UID --gid $USER_GID $USERNAME \
17
        && chmod -R $USER_UID:$USER_GID /home/$USERNAME \
18
        && chmod -R $USER_UID:root /usr/local/share/nvm /usr/local/share/npm-global; \
19
    fi \
20
    #
21
    # Install tslint, typescript. eslint is installed by javascript image
22
    && sudo -u ${USERNAME} npm install -g tslint typescript gitmoji-cli

So, when a GotQL codespace gets created, this is the environment we’ll have: an environment with a non-root user with sudo access, and tslint and TypeScript already installed. I also added gitmoji-cli, which is the commit convention I use in this project.

Then we have the devcontainer.json file, which is responsible not only for setting our editor’s configuration, but also for giving instructions to the codespace builder. In it, we define the codespace’s name, the extensions our online VSCode will have as soon as it starts, which Dockerfile it needs to use to build the system’s base, and we can also override VSCode’s own settings.

1
{
2
  "name": "TypeScript website codespace",
3
  "extensions": [
4
    "emmanuelbeziat.vscode-great-icons",
5
    "dbaeumer.vscode-eslint",
6
    "oderwat.indent-rainbow",
7
    "vtrois.gitmoji-vscode",
8
    "dracula-theme.theme-dracula",
9
    "2gua.rainbow-brackets",
10
    "ms-vscode.vscode-typescript-tslint-plugin"
11
  ],
12
  "dockerFile": "Dockerfile",
13
  // Set *default* container specific settings.json values on container create.
14
  "settings": {
15
    "terminal.integrated.shell.linux": "/bin/bash",
16
    "window.autoDetectColorScheme": true,
17
    "workbench.preferredDarkColorTheme": "Dracula",
18
    "editor.renderWhitespace": "boundary",
19
    "workbench.colorTheme": "Dracula",
20
    "workbench.iconTheme": "vscode-great-icons"
21
  },
22
  // Use 'postCreateCommand' to run commands after the container is created.
23
  "postCreateCommand": "npm install"
24
}

On top of that, we’ve added a postCreateCommand, which is extremely useful for running commands after the codespace has been created. In this case, we’re running npm install, so we already have every package installed by the time we open it.

We also have a great repository of examples of codespaces that can serve as a base for building your own. Let’s look at the setup.sh file from the Node codespace example.

1
## update and install some things we should probably have
2
apt-get update
3
apt-get install -y \
4
  curl \
5
  git \
6
  gnupg2 \
7
  jq \
8
  sudo \
9
  zsh
10

11
## set-up and install yarn
12
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
13
echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
14
apt-get update && apt-get install yarn -y
15

16
## install nvm
17
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
18

19
## setup and install oh-my-zsh
20
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
21
cp -R /root/.oh-my-zsh /home/$USERNAME
22
cp /root/.zshrc /home/$USERNAME
23
sed -i -e "s/\/root\/.oh-my-zsh/\/home\/$USERNAME\/.oh-my-zsh/g" /home/$USERNAME/.zshrc
24
chown -R $USER_UID:$USER_GID /home/$USERNAME/.oh-my-zsh /home/$USERNAME/.zshrc

This file is referenced inside the Dockerfile and runs as soon as it starts.

Conclusion#

Codespaces could become one of the leading technologies we have today, mainly because they allow for editing, or even more complex development work, using mobile devices like a phone.

Plenty of developers were already using Docker-based solutions to code on an iPad, but those solutions always ended up feeling more like duct tape than a proper solution.

With technologies and features like these emerging, we now have the ability to bring our work environment anywhere. Stay tuned for the next posts, where I’ll explain how I set up my remote work environment using GHC!

See you around!