Simplifying Open Source Contributions with Dev Containers
Table of Contents
During my first two weeks at Cloud Enablers I have started to look into Development Containers, among other things.
Development (or, in their short form, Dev) Containers are containers used for software development purposes. They are containers enriched with all the content and metadata necessary to be able to code inside them.
I have to admit that just reading the definition made me think, “Ok, then what? Why I should develop my code inside a container?”
Things got a bit clearer when I learned the benefits of using Dev Containers.
What are the benefits of using Dev Containers? #
Using Dev Containers allows you to:
- Use consistent tooling and library versions.
- Speed up development process.
- Reduce system conflicts.
- Facilitate the onboarding process.
- Centralize build and test automation.
With Dev Container you can create reproducible, pre-configured, isolated Dev environments.
Reproducible because, no matter the machine you are going to work on, once the container is up, the status of the project will be the same.
Pre-configured because you can specify which dependencies, IDE extensions, and libraries should be installed in order for you to immediately start to code.
And finally, isolated because it will be completely independent from your local machine and any of the sofwares installed on it.
Let’s look at how we can define a Dev Container.
Dev Container Specification #
The way you can add content and metadata to your container is by using the Development Container Specification.
Development Container Specification consists of a devcontainers.json file.
Depending on the tool or service you will use you, will find the JSON file in one of the following paths:
.devcontainer/devcontainer.jsondevcontainer.json.devcontainer/<folder>/devcontainer.json
I have been using VS Code, and the format used in that case is .devcontainer/devcontainer.json.
Below you can see and example of a devcontainers.json file.
{
"name": "the name of the dev container",
"image": "mcr.microsoft.com/devcontainers/typescript-node",
/* Product specific properties, defined in supporting tools */
"customizations": {
/* VS Code customization */
"vscode": {
"extensions": [
"yoavbls.pretty-ts-errors",
"infeng.vscode-react-typescript"
]
}
},
/* Features to add to the dev container. More info: https://containers.dev/features. */
"features": {
"ghcr.io/devcontainers/features/aws-cli:1": {},
"ghcr.io/devcontainers/features/git:1": {},
"ghcr.io/devcontainers-contrib/features/aws-cdk:2": {},
"ghcr.io/devcontainers-contrib/features/zsh-plugins:0": {}
},
/* Use 'postCreateCommand' to run commands after the container is created. */
"postCreateCommand": "npm install"
}
In the example I have reported just a few parameters to help you understand the concept of Dev Containers. For more properties, you can find the reference here.
image is the name of the image you want to get from a container registry, and that will be used to create the dev container.
This parameter is required, unless you would like to define the image yourself in a Dockerfile: in that case build.dockerfile would be required.
In the customizations parameter you will find the specific-tool properties. In the case above, I am using VS Code and defining which extensions I would like to install when creating the container.
Any feature represents, instead, a unit of code, or software you would like to install. In this example, I would like to install the AWS CLI, git, AWS CDK and the zsh shell.
If defined, postCreateCommand represents the commmand that will be run after the container is created. In my case, I would like that after the container is created, the npm install will be run.
Most popular supporting tools #
Dev Containers is a concept, a standard, a format that can be supported by several tools and services. I have been using VS Code, but GitHub Codespace is also quite popular.
You can find other supporting tools here.
Can you see the power now?
One of the first thing I have thought after delving into the topic was “This would be wonderful to have in Open source projects!”.
Dev Containers and Open Source: the perfect match! #
Maybe it’s me, but I often give up on contributing to some really interesting open source projects because it takes hours to try to setting up the whole environment and often the try is a complete failure. Thousands of errors to fix, it’s late at night and my sleeping slot is reducing dastrically. It is not worth it; I can’t.
Imagine cloning the open-source repo, open VS Code, launching the container with a bunch of clicks and in a couple of seconds (minutes in the case of bigger projects) a new VS Code window opens up, showing you the source code and being ready to develop. How awesome is that?
No more painful software installations and conflicts to fix with your installed tools on your machine, Way fewer issues in gitHub repos like “it does not work on OS XXX version XXX” and for sure, more people would feel more comfortable contributing.
AWS CDK for instance added a Dev Container specification and thanks to that I have started to contribute to the project.
Wrap up #
With Dev Container you can create reproducible, pre-configured, isolated Dev environments. This pecularity makes them perfect to use in open-soucrce projects to make the development easy and fast for all the contributors. Dev Containers are quite new standard and I have the impression that more and more teams and developer have started to use them. However, I still wish more open-source projects would provide a Dev Container setup for contributing.
That’s all folks! Let me know what do you think about this article at martina.theindiecoder@gmail.com.
See you soon! 🚀