Salesforce development in the browser with Github Codespaces

I’ve got an email from Github that the Codespaces function is finally publicly available in beta. So I can delete Visual Studio Code and SFDX from my computer. Woohoo!

Why? Codespaces is a fully functional Visual Studio Code environment, which you can use from a browser and it’s linked to a Github repository. This means that for almost any type of coding work you don’t need anything else, just a browser window and a Github account. In this post I review, how Salesforce development works with this new feature.

Codespaces is available currently for every individual Github user (looks like not available for corporate accounts at the moment). To start a Visual Studio Code editor in the browser, navigate to the code button in in your repo, and click ‘Open with Codespaces’.

This will set up you a container, with a clone of your repo and with a running instance of VSCode; then opens the user interface in your browser window. That how it looks like:

It is almost identical to the desktop version of VSCode, almost every key binding works the very same way.

The container-thing is important here. Behind the scenes, you have a fully functional linux-instance running in a Docker-container, so almost everything can be done here. Want to run node.js? Or python? Or vim? Perl? A Postgres database? No problem, you have all of this. SFDX? You can also install it.

The standard container-setup comes without SFDX, which is pretty much needed for any salesforce development. However, Salesforce was very nice, and created a Docker setup, which already includes all the SFDX essentials. So how to set up Codespaces to be immediately usable with SFDX?

The github documentation is pretty good, so following it you need to create those 2 files in the repo in which you work. As a starting point, use the samples from the sample repo

https://github.com/microsoft/vscode-dev-containers/tree/master/containers/sfdx-project/.devcontainer

.devcontainer/Dockerfile

This file defines the container setup. This is the official Salesforce image, but you can also write your own steps.

.devcontainer/devcontainer.json

This is the setup for the Codespaces VSCode editor. After Docker created the virtual environment, the configuration defines the VSCode settings. Look, you have here the list of extensions, for example: salesforce.salesforcedx-vscode

Here I’ve added a line, which defines the post-create steps.

The container already have SFDX, and with the inst.sh script (set in the postCreateCommadJSON property) I run the following steps:

The following is happening:

• Link my environment to the DevHub
• Create a sandbox and set it as the default scratch org
• Push codebase to the scratch org

This means when I start Codespaces, I already have everything ready, deployed and I can start immediately write code. (You can also run tests for example, or any other steps).

What is in the container?

The container uses this image: salesforce/salesforcedx.

If you look into the Docker file ( https://github.com/forcedotcom/salesforcedx-docker/blob/develop/dockerfiles/Dockerfile_full ), it has the following steps:

• node.js install
• JDK runtime install
• SFDX install

So if you think about it: all the steps, which you already made on your own computer — nothing more. Simple :)

What is missing?

You can write code, committing into your repo, deploy to scratch orgs (or production), run tests… and anything else, which can be run on a linux instance. So in theory, you can do all your salesforce development work from the browser. The container runs, even when you leave the window — so you can quit it, and come back later: the state remains active, until you stop the container instance.

For me, one feature is really missing: secret management. You see the following line in my post-install script:

sfdx force:auth:sfdxurl:store -d -f kl.txt -a devhub

This is VERY BAD, because i’ve put my dev-hub org keys into the repo! In order to do it properly, the key should be managed as a secret. The secret management feauture is already available in Github actions, so hopefully Github will enable it soon for Codespaces as well.

Another feature which is missing is color theme changing. Not a big thing, but I would be really happy to use in the browser my favorite magenta-background editor… :)

Will I use it every day?

Probably not, so I will keep SFDX installed on my mac. However, it can be a handy extra in some functions: I can jump in to any repo in no time, deploy the code into a new SFDX scratch org and prototype a new function. You can set up a default environment for your own Github account as well, so you can have SFDX out of the box, even if repo-wide SFDX Codespace setup in not available. In some situations in can be handy.

There’s one more thing: pricing. After public beta it will be no free anymore, and will start at $0.085 per hour. It’s not very expensive, but if it’s your default editor…can add 20 dollars to your costs every month. But I guess it won’t be your number one tool anyway, just a nice add-on.