setup-macos-developer

Depois de anos trocando de máquina — laptop pessoal, laptop de cliente, Mac Mini de laboratório — a conta que eu pagava não era o dia perdido instalando ferramentas. Era a semana seguinte: descobrir que o git tinha um alias diferente, que o node estava numa versão de dois anos atrás, que o terminal não tinha o mesmo tema e cada comando parecia estranho. Ambiente montado à mão não é lento — é irreproduzível.

Este repositório resolve isso do jeito mais simples que ainda funciona: scripts em Bash, versionados, que descrevem a estação de trabalho como código. O Homebrew instala o que é instalável por pacote; dotfiles carregam a configuração de shell, git e editor; o que sobra são ajustes do macOS que hoje eu faço clicando e amanhã não lembro onde ficava.

O critério de sucesso: rodar o mesmo comando em dois Macs e terminar com o mesmo ambiente. Não "parecido" — o mesmo. Se uma máquina diverge, a correção entra no repositório, não no histórico do terminal de uma máquina só.

Não é framework de dotfiles. Existem vários, alguns excelentes, e todos cobram um custo de aprendizado que não quis pagar por algo que rodo poucas vezes por ano. Bash puro é o que qualquer engenheiro lê em cinco minutos.

A ordem importa e é a mesma em toda execução. Primeiro o script confere se o Homebrew existe e instala se não — sem ele nada mais roda, então é o passo zero. Depois vem a lista de pacotes: formulae de linha de comando e casks de aplicativos, que o Homebrew processa em bloco. Só então os dotfiles são ligados ao $HOME por symlink, porque vários deles referenciam binários que acabaram de ser instalados. Por último, os ajustes do macOS que valem a pena automatizar: os que eu esqueço, e os que mudam comportamento de teclado e Finder.

Idempotência: o script foi escrito para ser reexecutado. Pacote já instalado é pulado, symlink existente não é recriado, e o Homebrew sabe ignorar o que já está na versão certa. É isso que permite usar o mesmo repositório para manter a máquina, não só para montar.

Bash de propósito: não há Python, Ansible nem Nix. Num Mac recém-formatado o que existe é zsh, bash e curl — tudo aqui roda com isso. O preço é menos abstração; o ganho é que qualquer pessoa abre o script e entende o que ele vai fazer com a máquina antes de rodar. Num script que pede a senha do administrador, isso não é detalhe.

Como o README é curto, a fonte de verdade sobre nomes de arquivo e flags é o próprio repositório. Leia o script principal antes da primeira execução; ele é o manual.

O repositório segue as regras do fernandofatech/platform, o mesmo lugar que governa meus outros projetos públicos. Branch com prefixo de tipo — feat/, fix/, chore/, docs/ — e commits em Conventional Commits. A versão sai dos commits; ninguém escreve número de versão à mão, e isso vale até para um repositório de scripts.

Por que tanta esteira para dotfiles: porque o custo não é o de escrever o script — é o de mantê-lo por anos sem que apodreça. O pr-lint recusa PR com título fora do padrão; o CI roda lint de shell; a varredura de segurança pega segredo colado por engano num .zshrc — e dotfile é exatamente onde token de API vai parar "só por hoje". O release automático marca cada mudança relevante, então dá para saber qual versão do setup montou qual máquina.

Corrigir a régua é mudar um arquivo no platform, não aqui. Esse é o ganho de centralizar: um repositório pequeno de scripts ganha a mesma disciplina de um serviço, sem carregar o YAML.

Se você for forkar, pode ignorar tudo isso: os scripts não dependem da esteira. Ela existe para o mantenedor, não para quem executa.