# Por que o Mole limpa menos cache do npm do que o npm cache verify

> Testes em cópias do cache levaram a uma limpeza mais estreita do npm, ao limite de idade do próprio Go e à revisão de saída de compilação em ferramentas globais e projetos antigos do Xcode.

Published: 2026-10-05 | Updated: 2026-10-18

Um usuário disse há pouco que o cache do npm ainda estava lá depois de uma passagem de manutenção do Mole, e que limpar por conta própria reduziu de 8 GB para 2 GB. Isso levou a outro olhar sobre caches de desenvolvedor: quais arquivos em cache ainda são necessários, quais perderam as referências e quais ferramentas já recolhem os próprios dados antigos.

A investigação e as mudanças descritas aqui foram feitas em 5 de outubro. Elas chegaram no Mole 1.16.0.

## Por que o cache do npm continua crescendo

O cache padrão do npm é `~/.npm/_cacache`. `content-v2` guarda pacotes e respostas do registro, enquanto `index-v5` mapeia pedidos para esse conteúdo. Os arquivos de conteúdo são nomeados por hash, e várias entradas do índice podem apontar para o mesmo arquivo.

Quando os metadados de um pacote mudam, o npm grava uma resposta nova. Consultas posteriores podem compactar entradas mais antigas do índice sem remover os arquivos de conteúdo, deixando arquivos sem referência no índice. A [documentação do npm](https://docs.npmjs.com/cli/v11/commands/npm-cache/) também diz que o cache não remove dados sozinho e cresce conforme pacotes são instalados.

O usuário já tinha limpado o cache, então eu não tinha uma cópia de antes da limpeza e não pude confirmar o comando exato que ele executou. O relato de 8 GB para 2 GB começou esta investigação; não é uma medição do Mole recuperando 6 GB, nem prova de que todos os 6 GB estavam sem referência.

## O que o verify removeu neste teste

O experimento usou cópias do cache do meu Mac com npm 11.19.1 e cacache 20.0.4. O original ficou intocado. Tinha cerca de um dia, com 309796162 bytes de conteúdo, e não um cache acumulado ao longo de vários meses.

| Regra | Arquivos de conteúdo | Bytes de conteúdo |
| --- | --- | --- |
| Sem referência de nenhuma entrada válida do índice | 1 | 614295 |
| Realmente apagados por `npm cache verify` | 6 | 25469972 |

A diferença vem da [implementação de verify do cacache](https://github.com/npm/cacache/blob/v20.0.4/lib/verify.js). Ela coleta o conteúdo, confere a integridade e reconstrói o índice, mantendo a última entrada de cada chave. Entradas anteriores ainda podem conter metadados completos e abreviados usados por pedidos diferentes; não são simplesmente cópias antiga e nova de uma resposta.

Na cópia, 11199796 bytes removidos pelo verify ainda eram referenciados por entradas válidas de outra variante de pedido. Algumas informações de pacote que podiam ser lidas offline antes da verificação passaram a devolver `ENOTCACHED` num `npm view` offline depois. Podiam ser buscadas de novo online, mas o comportamento do cache tinha mudado.

O Mole adota a regra mais estreita: qualquer entrada válida do índice mantém o conteúdo. Encontrar só cerca de 0,6 MB nesta amostra é preferível a expulsar uma variante utilizável só para se aproximar do resultado do verify.

## Limpar arquivos sem uso sem limpar o cache inteiro

A implementação nova analisa só o `~/.npm/_cacache` padrão. Conteúdo sem referência com mais de um dia aparece como uma linha selecionada por padrão na seção de desenvolvedor de Limpar. Remover o cache inteiro do npm ainda exige revisão, e seleções que se sobrepõem contam os bytes uma vez.

O Mole deixa esses arquivos em paz enquanto comandos como `npm install` ou `npm ci` estão gravando no cache. Se o índice não pode ser lido, os arquivos não são oferecidos para limpeza. As referências são conferidas de novo antes da exclusão; arquivos de índice e diretórios temporários ficam. O Mole não executa o comando de limpeza do npm em segundo plano.

Preservar referências do índice não garante que todo projeto consiga sempre compilar offline. Um lockfile pode pedir um tarball direto pelo hash, e registros privados ou versões antigas podem não continuar disponíveis. Arquivos-fonte, lockfiles e qualquer saída de compilação que não possa ser recriada ainda precisam ser guardados à parte. Locais personalizados do cache do npm ficam fora desta mudança.

## Go, Cargo e pnpm precisam de decisões diferentes

O Go já poda o cache de compilação. A [implementação](https://go.dev/src/cmd/go/internal/cache/cache.go) mantém entradas usadas nos últimos cinco dias mais uma margem de uma hora, ou 121 horas. O Mole antes oferecia o diretório inteiro do cache de compilação para limpeza padrão; esta mudança reduz isso à mesma regra de idade, mantendo entradas recentes que de outro modo teriam de ser recompiladas.

O Cargo já tem [coleta automática de cache](https://doc.rust-lang.org/cargo/reference/config.html#cache), e nada nesta amostra estava na hora dela. Uma remoção anterior de fontes extraídas do registro foi seguida, cerca de 29 horas depois, por aproximadamente 157 MB de downloads e 1,06 GB de descompactação. O Mole não acrescenta um coletor automático separado para esse depósito; as linhas de limpeza só para revisão que já existiam continuam disponíveis.

O depósito compartilhado do pnpm é diferente de novo. Na amostra em APFS, as contagens de hard link não conseguiam provar que o conteúdo estava sem uso; copiar esse critério selecionaria o depósito inteiro. Nenhum coletor novo de pnpm foi acrescentado. A contagem de hard links precisaria mostrar se um arquivo ainda está em uso naquele sistema de arquivos antes de o Mole poder usá-la para limpeza.

## Saída de compilação dentro de ferramentas globais e projetos antigos do Xcode

O `pake-cli` instalado globalmente continha uma pasta `src-tauri/target` de cerca de 1,48 GiB: saída Rust da compilação do shell Tauri, e não o cache de download do npm. Pastas de compilação assim, que carregam um `CACHEDIR.TAG` válido escrito pela ferramenta, agora são oferecidas para revisão. O Mole mantém a ferramenta instalada e as dependências em `node_modules`, e não oferece essas pastas enquanto uma compilação Rust está em execução.

O levantamento também encontrou 24 pastas de DerivedData do Xcode, cerca de 9 GiB, cujos caminhos de projeto registrados não existiam mais. Uma pasta inteira só é oferecida quando o projeto está confirmado como ausente no disco de inicialização e o Xcode não usou o cache correspondente há pelo menos duas semanas. Um disco externo ausente ou uma permissão de leitura negada não estabelece um projeto ausente. São achados daquele levantamento, não uma economia prometida em todo Mac; recompilar ainda leva tempo se a saída for necessária de novo.

## Confira qual camada você está limpando

Este comando só de leitura pede ao npm o local real do cache, inclusive um caminho personalizado configurado.

```bash
npm config get cache
```

Quando instalações e compilações tiverem parado de gravar nesse cache, decida se vai executar `npm cache verify`. Ele muda o cache; não é um comando só de inspeção. Pastas `node_modules` de projeto e comandos instalados globalmente são camadas separadas que ele não limpa. O [guia de cache de desenvolvedor](https://mole.fit/pt-br/blog/how-to-clear-dev-caches-mac) cobre o fluxo mais amplo.

---

Canonical HTML page: https://mole.fit/pt-br/blog/mole-developer-cache-gc
Blog index for agents: https://mole.fit/pt-br/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt