Higiene da máquina de desenvolvimento: npm, pip, Docker e além

Para onde vai mesmo o disco de um dev

Os quatro grandes acaparadores raramente surpreendem quem já olhou uma vez: caches de pacote crescem sem teto porque o padrão é esse, node_modules duplica a árvore de dependências em cada projeto, Docker conserva cada camada que baixou ou construiu, e o WSL2 guarda o sistema de arquivos Linux inteiro num disco virtual que cresce por demanda e nunca encolhe sozinho. Some os índices da IDE, os artefatos de build e três versões de SDK lado a lado — uma máquina de dois anos carrega sem esforço dezenas de gigabytes de lastro morto comprovado. Não há mistério: o lixo só está espalhado numa dúzia de diretórios onde você nunca entra.

• npm: %LOCALAPPDATA%\npm-cache — cópias completas de cada versão de cada pacote que você já instalou
• pip: %LOCALAPPDATA%\pip\cache — wheels de tudo quanto é coisa, mais ~/.cache/pip dentro de cada distribuição WSL
• Docker Desktop: imagens penduradas, contêineres parados, cache de build e volumes anônimos — docker system df mostra o total, docker system prune recupera
• WSL2: o arquivo de distribuição ext4.vhdx cresce a cada build e não devolve espaço sem uma compactação forçada
• Projetos: o node_modules de um repo abandonado pesa de centenas de MB a vários GB — o valor está no lockfile, a pasta se reconstrói
• IDEs: os diretórios de cache e índice do JetBrains, mais as pastas target/, build/, dist/, obj/ espalhadas pelos checkouts

A passada trimestral, na ordem certa

Meça primeiro, para a hora ir atrás da massa: uma ferramenta treemap sobre o perfil do usuário, docker system df pelo lado dos contêineres, wsl --list --verbose pelas distribuições. Depois trabalhe do seguro ao arriscado: caches se reconstruem por demanda, então purgue sem medo — npm cache clean --force, pip cache purge e os equivalentes no Gradle e no cargo; vêm em seguida os projetos abandonados — apague as pastas de dependências, guarde os lockfiles, e quando o repo acordar, npm ci ou pip install -r reconstrói tudo em minutos. Depois, Docker: fora imagens penduradas e cache de build, e ficam as imagens marcadas que você roda de verdade. Por último, o disco virtual do WSL2, porque apagar dentro da distribuição não encolhe o arquivo no lado do Windows: rode wsl --shutdown e compacte o vhdx — ou exporte e reimporte a distribuição se ela cresceu até o monstruoso.

Hábitos que mantêm o disco enxuto

Higiene como hábito sai mais barato que higiene como resgate. Mantenha as ferramentas por projeto em vez de instalações globais, deixe o CI baixar as imagens em vez de entesourá-las localmente, e rode docker system prune todo mês antes de o zoológico de camadas criar memória. Datasets de vários gigabytes vão para um segundo disco com um link — no disco do sistema fica só o que se regenera. E trate um C: quase cheio como incidente de build, não como cosmética: npm, Docker e a toolchain de compilação começam a falhar das maneiras mais inventivas quando acaba o espaço onde eles coçam.

Perguntas e respostas

Continue lendo