Best practices for keeping my macOS development environment clean and efficient

02 Ağu 12:01

أهلاً وسهلاً، أحب أشارك معكم الترتيب اللي أتبعه على macOS لأنه فعلاً بيخليني أشتغل بسرعة وأقّل مشاكل التحديثات. أول شيء أفضّل الـ **zsh** مع **oh‑my‑zsh** لأن الإضافات (plugins) مثل `git`, `docker` و`npm` بتعطي تنبيهات فورية. بأقفل كل إعداداتي في ملف `.zshrc` وأحفظه على Git مع باقي الـ dotfiles باستخدام **GitHub**؛ كل مرة أعمل clone جديد على جهاز جديد أطبق `brew bundle` و`./install.sh` لتثبيت الأدوات تلقائياً. بالنسبة لإدارة الحزم، أستخدم **Homebrew** كقائمة أساسية وأضيف `Brewfile` في مستودع الـ dotfiles عشان يثبت كل الحزم اللي أحتاجها (Node via **volta** أو **nvm**, Docker, PostgreSQL …). لإدارة إصدارات اللغات أستغل **asdf** مع plugins للـ node, python, ruby … و **direnv** لتفعيل البيئة المحلية حسب المجلد، فبدون ما أخلط بين المشاريع. في محرر الشيفرة أفضّل **VS Code** مع إعدادات sync عبر Settings Sync، وأضيف ملحقات مثل `Prettier`, `ESLint` و `Live Share` لكل مشروع. وأخيراً، أعتمد على سكريبتات Makefile أو `justfile` لآليات الـ build والـ test، و‑`brew upgrade --greedy` بصورة دورية مع مراقبة تغييرات الـ brew formulas لتجنب كسر الإعدادات بعد تحديث macOS. باختصار، الجمع بين Git لإصدار الـ dotfiles، وإدارة إصدارات متعددة عبر asdf + direnv، وتوحيد التثبيت عبر Brewfile بيخلي البيئة خفيفة، قابلة للتوسيع، وتتحمل التحديثات.

02 Ağu 12:50

For the shell I usually stick with **zsh** (the default on recent macOS) together with **Oh My Zsh** or a minimal framework like **zinit**. Pick a small set of plugins—git, npm, pyenv, and a history‑searcher—and keep the rest in 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 avoids pulling everything into every new terminal session and keeps startup time under a second. Package management in the macOS world 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 `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 dramatically reduces disk usage and speeds up installs. A global `pnpm` installation via Homebrew, then a per‑project `pnpm install --shamefully-hoist` when you need a monorepo layout, works nicely. Dotfiles versioning is where I lean 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 guard against macOS updates 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 re‑install missing formulae and verify the environment. Automation-wise, I use **Makefile** targets for common chores (`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?