Setting Up a Modern Front-End Development Environment on macOS
Just the other week I decided to erase the contents of my early 2015 MacBook Pro, reinstall macOS, and set up a brand new front-end development environment from scratch – without a backup.
Descending into madness
I’m someone who welcomes abrupt change in many forms. To me, it doesn’t seem particularly crazy to erase my entire hard drive and set it up again from scratch. Besides, isn’t there something calming about having a clean slate from which to work and build anew? To revert your computer to the state you saw it in when you pulled back the tabs and slid it out of its pristine box is a neat feeling–it allows you to go through the onboarding experience and feel like you’re setting it up for the first time all over again.
Preparing for total computer erasure
I’ll admit I was apprehensive about beginning this process, but only a tiny bit. The anxiety was lessened because I felt safe knowing I had a bunch of things backed up in iCloud Drive (e.g., documents, photos).
Still, as a developer, I have many files related to development that have been modified here and there with various configuration or quality of life improvements (e.g., `.zshrc` or `.npmrc`).
Naturally, I wanted to keep some of those files so I wouldn’t have to set them up to my liking again.
Versioning your dot files with git
We’ve had a solution to not having to recreate dot files all along – git! After reading this article by Mohammad Ajmal Siddiqui on versioning your handy dot files with git, I decided that was a brilliant idea and did so myself with danieldafoe/dots.
That’s it. That’s all I did in preparation. Now let’s get into setting up my development machine again.
Getting my favourite applications back
If you’ve had a computer before and you get a new one, what do you do first? That’s the question I was struck with first after my squeaky clean MacBrook Pro with macOS Catalina started up.
For me, I started by downloading the programs I knew I wanted back.
Spectacle
Free window management (e.g., snapping, resizing) software with keyboard shortcuts. Of note: it’s no longer actively maintained, but it’s perfectly usable. Learn more about Spectacle.
Worthy note: I just learned about a newer window management application called Amethyst from someone at work. It’s even open source, so you’re free to open issues, request features, or work on it yourself. Learn more about Amethyst.
Alfred
A faster and more feature-rich replacement for macOS’s Spotlight search. Of note: you can map Alfred to show up instead of Spotlight with `cmd+spacebar`. Learn more about Alfred.
Hyper
A terminal built with web technologies that has a lot of potential for customization. Learn more about Hyper.
Figma
An interface design and prototyping tool. When inspiration hits, I want to quickly jump into a blank canvas and put onto virtual paper what my brain has conjured up. It’s been my go-to since it came out, and that’s not just because I was reluctant to jump on board with Sketch. Learn more about Figma.
Google Chrome
It’s been my go-to development browser for years. I was blown away when it first got a responsive design view. Also of note: lot of nice extensions.
Firefox
You’re a front-end developer, right? Always test your projects in another browser. Of note: the focus on CSS Grid debugging and recent accessibility improvements.
Visual Studio Code
My preferred lightweight IDE. Of note: git integration and browser debugging integrations by default. You’ve probably heard of it already, but you can learn more about Visual Studio Code here.
Installing command-line tools
What seems to have gained a lot of attention in the front-end realm is developers knowing their way around a terminal. I suppose it’s a side effect of things like code bundlers, build systems, and transpilers gaining a lot of popularity in the front end world. Regardless of the rhyme or reason, I think it’s a great skill to have. Additionally, it always feels strangely empowering to learn new things.
That said, let’s get into what I did to my terminal.
Ditch Terminal
This was mentioned in the previous section when I mentioned downloading Hyper (a terminal substitute), but I thought I’d mention it again. While terminal will get the job done just fine, I appreciate the customization Hyper affords.
zsh
I’ve read elsewhere online that macOS has now adopted zsh as its standard shell by default, but the default I got when I reinstalled macOS was bash.
Bash is a capable companion, sure, but zsh has opened too many doors for me to stick around with bash.
Not only that, but once you’re using zsh, oh-my-zsh is but a curl request away.
z
Shortest section heading to ever appear on Medium? Maybe. It’s also the name of a helpful little utility for zsh that allows you to jump around to frequent directories you visit in terminal, regardless of their relativity to whatever directory you’re currently in.
For example, imagine you’re in
~/code/projects/foo/src/app/
but now you need to get to
~/code/projects/bar/src/components/bar-component/
Previously you’d do something like,
cd ../../bar/src/components/bar-component
Sure, you may have tab autocompletion to make that a bit easier on yourself, but let’s compare that to how we might do it using z.
z bar
Yeah. It’s that good.
nvm
Being a Node version manager, nvm lets you quickly change the version of Node — and by extension npm — that is currently active on your operating system.
yarn
While npm is still the favourite child of the web development package manager world, yarn is a truly capable younger sibling. Marketed as a quicker alternative to npm, I decided to give it a shot as my default package manager this time around.
Hindsight
After any experience, sometimes there are mistakes that are made. This section is about those things you look back on and wish you’d considered a little more–or at all.
Working Changes in Code Projects
Normally, all of my code projects live under ~/projects/ on my laptop. While that may not seem important, you may change your mind if I tell you I didn’t exactly go through all of the 50+ folders (not all uploaded to GitHub) in there to ensure I wasn’t leaving behind any working changes on a repository. Oops.
Fortunately, that’s all I really left behind in the wake of this decision. Not a huge mess considering a lot of the unfinished repositories in there were likely from over 6 years ago.
All in all, this was a fun experience. I enjoyed being able to set up my machine again as if it were brand new and pick and choose the applications I wanted on my machine. Only what I truly needed.
We all know how quickly our file system devolves into dotfiles upon dotfiles among config files. It’s been nice living in a file system without so much of that extra cruft. It’s been refreshing. I think I like this view.
