install.shis the bootstrap entry point for new macOS machines; it fetches the repo, installs Homebrew, and runsbin/dotfiles.bin/holds the primary CLIs (e.g.,bin/dotfilesfor syncing/linking dotfiles,bin/macosdefaultsfor macOS tweaks, app launchers).lib/contains shared shell helpers (brew/composer/node/pip/utils/zsh) sourced by the CLIs; keep shared logic here.functions/andoh-my-zsh-custom/define zsh functions, aliases, paths, and exports loaded by.zshrc.dotfiles/stores the tracked configuration files that get symlinked or mirrored into$HOME(zshrc,gitconfig,curlrc, etc.).
./install.sh [--configure-macos] [--install-casks]— full bootstrap; only run on macOS with Xcode CLT installed.zsh bin/dotfiles --help— show available flags for syncing (packages, macOS defaults, casks).zsh bin/dotfiles --no-sync --no-packages— re-link dotfiles without pulling or touching packages; safe for iterative edits.zsh bin/macosdefaults— apply macOS defaults independently if you skipped them during install.git pull --rebase origin main— preferred update path before hacking; keeps local scripts aligned with upstream helpers.
- Shell scripts use a mix of POSIX
sh,bash, andzsh; keep the existing shebang and avoid introducing new language dependencies. - Prefer 2-space indentation, lower_snake_case function names, and explicit
localdeclarations inside functions. - Source shared helpers from
lib/instead of reimplementing logging, prompts, or platform checks. - Keep user-facing output terse and colored via
lib/utilshelpers (e_header,e_warning,e_success). - Place personal overrides in
~/.zshrc.beforeor~/.zshrc.afterinstead of modifying tracked files.
- Smoke-test provisioning steps you touch: run
zsh bin/dotfiles --no-sync --no-packagesto confirm linking and flag handling. - For scripts invoked by
install.sh, verify they run under/bin/shwhere applicable and avoid zsh-only syntax unless the shebang is zsh. - Optional: run
shellcheckonsh/bashscripts when making non-trivial edits to catch portability issues. - If you add new helpers in
lib/, ensure they are idempotent and safe to re-run; prefer mockable checks (e.g.,formula_exists) over direct installs in tests.
- Use short, imperative commit subjects (e.g., “Add brew check for gh”) with concise bodies explaining context or risk.
- Keep changes scoped: one concern per commit/PR; avoid mixing macOS defaults, package lists, and dotfile tweaks in a single change.
- Reference related issues if present and describe any manual steps required after merging (e.g., rerun
bin/dotfilesorbin/macosdefaults). - Include examples or command snippets in the PR description when behavior changes (new flags, renamed functions, or added dependencies).
- Do not commit secrets or machine-specific credentials; prefer
~/.zshrc.before/afterfor private data andgit config --globalfor author info. - When adjusting Homebrew, cask lists, or defaults, confirm they are safe for a broad macOS audience and guard machine-specific logic with checks (e.g.,
is_apple_silicon). - Be explicit about networked actions; note when a script downloads tarballs or taps new formulae so reviewers can assess risk.