# Estratégias de cache de dependências para um CI mais rápido

> Rebaixar dependências a cada execução é tempo desperdiçado. Aprenda o que cachear, como chavear no lockfile e as armadilhas que matam a taxa de acerto.

Source: https://latchkey.dev/pt/learn/ci-cd-concepts/dependency-caching-strategies  
Updated: 2026-06-25

O maior e mais barato ganho de velocidade no CI é não rebaixar as mesmas dependências a cada execução. Cacheie o package store, chaveie no lockfile e a maioria das instalações fica quase instantânea.

A instalação de dependências domina muitos jobs de CI. Uma boa estratégia de cache restaura o package store de uma execução anterior para que o instalador só busque o que de fato mudou - transformando minutos em segundos.

## Cacheie o store, não o projeto

Prefira cachear o store global ou download cache do gerenciador de pacotes (npm cache, `~/.m2`, pip wheel cache, Cargo registry) em vez de um diretório de projeto como `node_modules`. O store é portável e permite ao instalador fazer uma instalação rápida e validada em vez de confiar cegamente em arquivos copiados.

## Chaveie no lockfile

A cache key deve mudar exatamente quando as dependências mudam - um hash do lockfile (`package-lock.json`, `poetry.lock`, `Cargo.lock`). Mesmo lockfile → mesmo cache → acerto total. Lockfile alterado → nova entrada de cache, e um fallback de restore-key recupera a maior parte do store anterior.

```Lockfile-keyed cache
key: deps-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
  deps-${{ runner.os }}-
```

## Armadilhas comuns

- Chavear em um valor que sempre muda → taxa de acerto de 0%.
- Cachear `node_modules` diretamente, ocultando o drift do lockfile.
- Não incluir OS/arch na key → restaurar binários incompatíveis.
- Cachear mais rápido do que você invalida, servindo deps transitivas obsoletas.

## Meça o retorno

Compare o tempo de instalação em um acerto de cache vs uma execução a frio; se forem similares, o cache não está acertando. Um cache de dependências saudável deve transformar uma instalação de vários minutos em segundos, e a taxa de acerto deve ser alta em branches que não tocam no lockfile.

## FAQ

### What is Dependency caching strategies for faster CI?

Dependency installation dominates many CI jobs. A good caching strategy restores the package store from a previous run so the installer only fetches what actually changed - turning minutes into seconds.

### Cache the store, not the project?

Prefer caching the package manager’s global store or download cache (npm cache, ~/.m2, pip wheel cache, Cargo registry) over a project directory like node_modules. The store is portable and lets the installer do a fast, validated install rather than blindly trusting copied files.

### Key on the lockfile?

The cache key should change exactly when dependencies change - a hash of the lockfile (package-lock.json, poetry.lock, Cargo.lock). Same lockfile → same cache → full hit. Changed lockfile → new cache entry, and a restore-key fallback recovers most of the previous store.

### Measure the payoff?

Compare install time on a cache hit vs a cold run; if they are similar, the cache is not hitting. A healthy dependency cache should turn a multi-minute install into seconds, and the hit rate should be high on branches that do not touch the lockfile.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt