Limpe caches de desenvolvimento sem quebrar o build

O armazenamento de desenvolvimento está fragmentado entre downloads de pacotes, saída de build, SDKs, bancos locais e árvores de dependência por projeto. Parte é reproduzível, parte depende de um lockfile e de um registro que pode sumir depois, e parte é dado local único. Uma limpeza segura prova que tipo encontrou, em vez de presumir que toda pasta oculta é cache.

Os caches globais, por ferramenta

Cada gerenciador de pacotes mantém um store global que você pode medir direto:

du -sh ~/.npm ~/.cargo ~/.cache/pip ~/Library/Caches/pip ~/.gradle 2>/dev/null | sort -h

Esses são padrões, não uma promessa. Peça à ferramenta o caminho configurado quando der, por exemplo npm config get cache, python -m pip cache dir e pnpm store path.

• npm guarda downloads em cache em ~/.npm por padrão. Comece com npm cache verify; o npm descreve o cache como autocicatrizante, então npm cache clean --force serve sobretudo para recuperar espaço de propósito ou para diagnóstico.
• Cargo guarda registros e checkouts de git em ~/.cargo, mas o Cargo home também pode conter binários instalados, configuração, registros de pacotes e credenciais de registro. O Cargo atual remove periodicamente entradas não usadas do cache global durante comandos de build e de fetch. Deixe essa política trabalhar, ou inspecione os subdiretórios exatos de cache. Nunca remova ~/.cargo inteiro.
• pip guarda wheels e respostas HTTP em ~/Library/Caches/pip por padrão. python -m pip cache info informa o local e o tamanho reais, enquanto python -m pip cache purge limpa o cache.
• pnpm e yarn mantêm os próprios stores; pnpm store prune e yarn cache clean podam pacotes sem referência ou em cache. Confira a versão ativa do gerenciador, porque o layout do store e o comportamento de cache local versus global diferem.
• Gradle e Maven (~/.gradle, ~/.m2) podem ser enormes em Macs de Android e JVM. O Gradle já faz limpeza periódica de cache; pare os daemons dele antes de uma revisão manual. Um repositório Maven pode conter artefatos construídos localmente ou privados que não dá para baixar de novo, então inspecione em vez de apagar o repositório inteiro por padrão.

O custo pode incluir um download grande, uma recompilação nativa ou um build histórico que falha quando uma versão do registro sumiu. Confira o lockfile e a origem de cada dependência antes de chamar um store de reproduzível.

Caches de IDE são outra camada. IDEs da JetBrains guardam caches, índices e o Histórico Local em ~/Library/Caches/JetBrains, e caches da JetBrains no Mac explica quais partes se reconstroem. O Android Studio, embora construído na mesma plataforma, guarda os caches em ~/Library/Caches/Google/AndroidStudio* em vez disso.

O problema espalhado do node_modules

A surpresa maior em geral não é um cache só, e sim as pastas node_modules espalhadas por cada projeto JavaScript em que você já mexeu. Cada uma é autocontida e costuma ter de 200 a 500 MB, então dez projetos antigos podem esconder vários gigabytes. Ache-as e os tamanhos:

find ~/www ~/Projects -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null

Troque as raízes de exemplo pelas pastas onde você guarda projetos. -prune impede o find de descer numa árvore de dependências encontrada, e -exec lida com espaços e caracteres incomuns nos caminhos com segurança. Um projeto só recompõe as dependências quando o código-fonte, o lockfile, a versão do gerenciador, o acesso ao registro e a cadeia de ferramentas nativa necessária ainda estão disponíveis. Prefira o comando específico do lockfile, como npm ci, depois de preservar essas entradas.

Não apague isto

Caches de pacotes podem ser substituíveis, mas código-fonte, manifestos e lockfiles do projeto não. package.json é um manifesto; package-lock.json e Cargo.lock são lockfiles. Eles definem o build, então nunca os varra junto. Apagar um store global ativo, como um store do pnpm compartilhado entre projetos, pode interromper a instalação ou exigir downloads que não estão mais disponíveis. Pare builds e instalações e então use a limpeza documentada do gerenciador de pacotes.

Por dentro: stores endereçados por conteúdo, e por que o node_modules é a exceção

Muitos gerenciadores de pacotes usam stores endereçados por conteúdo para reduzir downloads repetidos. O pnpm mantém um store global de cada versão de pacote e cria hard links deles no node_modules de cada projeto, então dez projetos que usam a mesma biblioteca compartilham uma cópia só no disco. Os caches do Cargo e do Go também indexam o conteúdo baixado por versão ou checksum. Isso protege a integridade, mas não garante disponibilidade futura. Uma instalação convencional do npm materializa uma árvore de dependências por projeto, enquanto o pnpm pode ligar projetos a um store compartilhado. É por isso que apagar um diretório node_modules e podar um store compartilhado têm raios de impacto diferentes.

Use mapas para descobrir e gerenciadores de pacotes para limpar

A natureza espalhada é o problema de descoberta. Um mapa de árvore como a visualização Analisar do Mole pode revelar qual projeto ou store é grande, mas o comando de verificação, poda ou limpeza do próprio gerenciador entende o índice e as referências. Use o mapa para escolher um alvo e a ferramenta dona para mudá-lo.

Uma ordem segura de operações

Pare builds e daemons, meça raízes de projeto escolhidas, confira os stores do gerenciador e preserve código-fonte e lockfiles antes de remover uma árvore de dependências. Use comandos de poda documentados em vez de apagar uma pasta oculta inteira do diretório pessoal. Reconstrua um projeto antes de esvaziar o Lixo. O propósito é remover saída reproduzível e reter a informação necessária para reproduzi-la.