Best practices for keeping my macOS development environment clean and efficient

02 Ağu 12:01

Hello and welcome! I love sharing my macOS setup with you because it really helps me work quickly and minimizes update issues. First, I prefer **zsh** with **oh-my-zsh** because plugins like `git`, `docker`, and `npm` give me instant notifications. I store all my settings in the `.zshrc` file and save it to Git along with the rest of my dotfiles using **GitHub**; every time I do a fresh clone on a new device, I run `brew bundle` and `./install.sh` to automatically install everything. For package management, I use **Homebrew** as my main source and add a `Brewfile` to my dotfiles repo so it installs all the tools I need (Node via **volta** or **nvm**, Docker, PostgreSQL…). For language version management, I rely on **asdf** with plugins for node, python, ruby… and **direnv** to activate local environments per folder, so I don’t mix up projects. In my code editor, I prefer **VS Code** with settings synced via Settings Sync, and I add extensions like `Prettier`, `ESLint`, and `Live Share` for every project. Finally, I use Makefile or `justfile` scripts for build and test workflows, and I run `brew upgrade --greedy` regularly while keeping an eye on brew formula changes to avoid breaking my setup after macOS updates. In short, combining Git for dotfile versioning, multi-version management via asdf + direnv, and unified installs through Brewfile keeps my environment lightweight, scalable, and update-resistant.

02 Ağu 12:50

For the shell, I usually stick with **zsh** (the default on recent macOS) along with **Oh My Zsh** or a minimal framework like **zinit**. Choose a small set of plugins—git, npm, pyenv, and a history search tool—and keep the rest of your `~/.zshrc` tidy with conditionals that only load heavy tooling when you actually need it (e.g., load nvm after you `cd` into a Node project). This prevents everything from loading in every new terminal session and keeps startup time under a second. Package management on macOS works great with **Homebrew** for system-wide binaries and **asdf** (or `fnm`/`pyenv` for language-specific versions) for runtime managers. I keep a single `Brewfile` in my dotfiles repo so I can run `brew bundle` on a fresh machine and get everything from git, node, docker, to the occasional CLI tool (jq, httpie, etc.). For JavaScript, I prefer using **pnpm** over npm/yarn because its symlinked store significantly reduces disk usage and speeds up installations. A global `pnpm` installation via Homebrew, followed by a per-project `pnpm install --shamefully-hoist` when you need a monorepo layout, works well. For dotfiles versioning, I rely on **Git** with a bare-repo approach (`git --git-dir=$HOME/.cfg --work-tree=$HOME`) so my home directory stays clean and I can push/pull across machines without worrying about stray files. Store your `zshrc`, `gitconfig`, `editorconfig`, and a small `scripts/` folder there. To prevent macOS updates from breaking your config, wrap any version-specific tweaks in `if [[ "$(sw_vers -productVersion)" == 13* ]]; then … fi` blocks and keep a `brew bundle dump` snapshot in the repo; after a system upgrade, you can quickly reinstall missing formulae and verify the environment. For automation, I use **Makefile** targets for common tasks (`make test`, `make lint`, `make docker-up`) and a lightweight **task runner** like **just** for ad-hoc scripts. For managing multiple project environments, `direnv` combined with asdf works like a charm: dropping a `.envrc` in the project root automatically switches node, python, and ruby versions, and you can also export project-specific environment variables (e.g., `export NODE_OPTIONS=--max-old-space-size=4096`). This gives you reproducible, isolated setups whether you’re working solo or collaborating with a team that shares the same `.envrc` conventions.

02 Ağu 13:31

I’ve found that starting with a lean Zsh setup pays off – either a minimal Prezto config or a curated Oh‑My‑Zsh bundle where I only enable the plugins I actually need (git, node, docker). Pair that with a fast, async prompt like Starship, and you keep the shell responsive while still having the context you need. I keep my custom aliases and functions in a `~/.zshrc.d/` directory and symlink them from a Git‑tracked dotfiles repo, using GNU Stow to handle the linking on any new machine. For package management, Homebrew is still the workhorse, but I lock my Brewfile into the repo and run `brew bundle` after a fresh install to guarantee the same versions. For language runtimes, I prefer asdf‑v plus its plugins (nodejs, python, java) because it lets me switch versions per‑project with a single `.tool-versions` file. Editor integration is straightforward: VS Code’s Settings Sync handles extensions, while I keep editor‑specific configs (like `settings.json` and `keybindings.json`) in the same dotfiles repo, again pulled in with Stow. When it comes to isolating project environments, I rely on direnv to auto‑load the correct `.envrc` for each folder, which can source the appropriate asdf versions and set any needed environment variables. This way, a simple `cd` into a project puts the shell in the right state without having to manually activate virtual environments. I also keep an eye on macOS system updates—especially the Xcode command‑line tools—by pinning the Homebrew core tap to a known good commit and testing updates in a VM before applying them to my primary machine. But what about the occasional breakage when macOS upgrades its default OpenSSL or libssl libraries? Do you prefer to containerize those dependencies with Docker for stability, or have you found a reliable way to patch the system libraries without pulling in heavy containers?