# Limpe caches de desenvolvimento sem quebrar o build > Preserve o código-fonte, os lockfiles, o acesso ao registro e os artefatos locais únicos antes de podar stores de pacotes e árvores de dependência. Published: 2026-06-03 | Updated: 2026-10-18 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`](https://docs.npmjs.com/cli/commands/npm-cache); 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](https://doc.rust-lang.org/cargo/guide/cargo-home.html) 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`](https://pip.pypa.io/en/stable/cli/pip_cache/) limpa o cache. - **pnpm** e **yarn** mantêm os próprios stores; `pnpm store prune` e [`yarn cache clean`](https://yarnpkg.com/cli/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](https://docs.gradle.org/current/userguide/directory_layout.html); 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](https://mole.fit/pt-br/blog/jetbrains-caches-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.
À esquerda, um store global compartilhado com hard links em vários projetos; à direita, a mesma biblioteca copiada no node_modules de cada projeto, duplicada.
Um store compartilhado endereçado por conteúdo e uma árvore de dependências materializada por projeto têm custos de armazenamento diferentes e limites de limpeza 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](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/pt-br/blog/how-to-clear-dev-caches-mac Blog index for agents: https://mole.fit/pt-br/blog/llms.txt Site index for agents: https://mole.fit/llms.txt