Never Setup A Development Environment From Scratch Again

This is a sister post to a series of YouTube videos titled "Build A Portable Development Environment".

As software developers, we rely on many tools. Some of these tools exist in the command line like git and vim. They themselves rely on configuration files like .gitconfig and .vimrc. We call these dotfiles.

They are pieces of configuration that instruct our tools on how to operate. Over time you will collect a number of them on your computer. They could be files you manually create yourself, or ones that get generated automatically.

Whatever the case, some of them will be crucial to your workflow. Therefore these files should not only exist on your computer, but any of your future computers. How? One way is to use GitHub. Dotfiles in the cloud - so that the next time Tim Cook announces a fancy new laptop you can run to Best Buy with confidence!

The problem with just storing your dotfiles in GitHub is that you still have to do everything else that comes with setting up a new development environment. This is inefficient in my book. I want to be able to run a single command and build my entire environment at once: installing and configuring all of my tools, setting up my shell, etc.

For the last two months I've set out to solve this problem for myself. Here's how I did it:

Step 1 - Identify your tools

If you don't have any management system for your configuration files, the first step is to take stock of what you actually use. Which tools are most important to you? Maybe this is a good time to remove some that you don't use anymore.

Keep a list of all the tools you want to take with you throughout your development career, and keep it close. We will reference it in the coming steps.

Step 2 - Adopt a cross-platform package manager

Most of the tools that you rely on will need to be installed somehow. MacOS users usually solve this with homebrew. Linux users have a number of options such as apt-get.

The problem with both is that they are not cross-platform.

This is why I recommend the Nix package manager. It is a cross-platform package manager that can be used to install most of the tools you use everyday. Adopting it means your future self is protected in the event you decide to jump ship from MacOS to Linux or vice-versa.

Sorry Windows users, I can't help you.

Check out my YouTube video on getting setup with the Nix package manager.

Step 3 - Organize your dotfiles

This is the step where your OCD can really kick in. Reference the list of tools you made in step 1. Some (not all) of them will have configuration files. You will need to locate these files and move them to a common directory that can be versioned with Git.

I wrote an article on how to do this titled Manage Your Dotfiles Like A Superhero. If you are a visual learner, there is a YouTube video as well.

Step 4 - Create your install script

This is the core of the whole solution: an executable script named install.sh that lives alongside your dotfiles in GitHub. In this script you can execute a series of synchronous commands that will setup your development environment.

An example of the steps I take in my own installation script:

  • Install nix
  • Install packages via nix
  • Place dotfiles in the home directory
  • Setup the default shell
  • Configure other tools like vim

I explain how to use this installation script in this video.

Step 5 - Push to GitHub

Once you've organized everything into a common directory and your installation script has taken shape, it's time to push to GitHub.

Congratulations! Your development environment is now portable. Enjoy never having to set one up from scratch again. Any changes you make to your setup can be pushed to GitHub. Future proof. Version history. Profit!

Check out my dotfiles repository in GitHub.

Conclusion

This is by no means the only way to achieve such an outcome. It works for me, and I share it with you in the hopes that you get inspired to craft your own solution.

If you found this series useful, let me know on Twitter! And if you have suggestions on how this process can be improved, I would love to know!

Jake Wiesler

Hey! 👋 I'm Jake

Thanks for reading! I write about software and building on the Web. Learn more about me here.

Subscribe To Original Copy

A weekly email for makers on the Web.

Learn More