# Mettre en cache Composer et npm dans GitHub Actions pour des builds rapides

> Éviter de retélécharger les mêmes paquets à chaque exécution de pipeline grâce à l'action officielle de cache, avec un vrai gain de temps mesuré.

- Auteur : Clément Hadrot
- Publié le : 2022-08-28
- Mis à jour le : 2022-08-28
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/cache-composer-npm-github-actions-builds-rapides/

## L’essentiel

- L'action officielle actions/cache suffit dans la majorité des cas
- La clé de cache doit dépendre du fichier de verrouillage
- Un cache mal invalidé installe silencieusement de vieilles dépendances

Un pipeline GitHub Actions qui réinstalle intégralement les dépendances Composer et npm à chaque exécution paraît anodin sur un petit projet, mais devient vite pénalisant sur un projet WordPress avec de nombreuses dépendances PHP et un build front conséquent : chaque exécution attend le téléchargement complet de paquets qui n'ont pourtant pas changé depuis la veille. L'action officielle `actions/cache` permet de conserver ces dépendances entre les exécutions, à condition de la configurer correctement.

Ce réglage n'a rien de spectaculaire techniquement, mais il concentre plusieurs pièges classiques : une clé de cache mal choisie peut soit ne jamais se réutiliser (aucun gain), soit pire, réutiliser un cache obsolète et installer silencieusement d'anciennes versions de paquets.

## Mettre en cache Composer

> L'essentiel à retenir : L'action officielle actions/cache suffit dans la majorité des cas ; La clé de cache doit dépendre du fichier de verrouillage ; Un cache mal invalidé installe silencieusement de vieilles dépendances

```
- name: Récupérer le chemin du cache Composer
  id: composer-cache
  run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT

- name: Mettre en cache les dépendances Composer
  uses: actions/cache@v3
  with:
    path: ${{ steps.composer-cache.outputs.dir }}
    key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
    restore-keys: |
      ${{ runner.os }}-composer-
```

Le point essentiel ici est la clé de cache, construite à partir du hachage du fichier `composer.lock`. Tant que ce fichier ne change pas, le cache existant est réutilisé ; dès qu'une dépendance est mise à jour et que le lock change, une nouvelle clé est générée et un cache frais est constitué.

## Mettre en cache npm

```
- name: Mettre en cache les dépendances npm
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-
```

Une alternative plus simple existe pour npm : l'action officielle `actions/setup-node` propose une option `cache: npm` intégrée, qui gère automatiquement cette logique sans configuration manuelle de clé :

```
- uses: actions/setup-node@v3
  with:
    node-version: '18'
    cache: 'npm'
```

## Le piège des restore-keys trop larges

Les `restore-keys` permettent de retomber sur un cache partiel même si la clé exacte n'existe pas (par exemple après une mise à jour mineure d'une seule dépendance). C'est utile pour éviter un cache totalement vide, mais cela signifie aussi qu'un cache partiellement obsolète peut être restauré : Composer et npm revérifient ensuite l'intégrité par rapport au fichier de verrouillage, donc aucune version incorrecte n'est installée silencieusement, mais le gain de temps est partiel plutôt que total dans ce cas précis.

## Mesurer le gain réel

| Étape | Sans cache | Avec cache (clé valide) |
| --- | --- | --- |
| Installation Composer | ~45 secondes | ~8 secondes |
| Installation npm | ~90 secondes | ~15 secondes |
| Durée totale du job | ~4 minutes | ~1 minute 20 |

## Un point d'attention sur les secrets

Un dépôt Composer privé (Satis interne ou Packagist privé) demande des identifiants d'authentification pendant l'installation, distincts du cache lui-même : ces identifiants doivent rester dans les secrets d'environnement de GitHub Actions, jamais dans le cache, qui reste accessible à toute exécution du même dépôt, y compris depuis une pull request externe sur un dépôt public.

> Un cache mal borné n'est jamais une faille de sécurité en soi, mais il ne doit jamais être confondu avec un espace de stockage de secrets : sa seule fonction est d'accélérer une réinstallation identique.

## Ce que le cache ne résout pas

- Un build front lent à cause de la compilation elle-même (Sass, transpilation JS) n'est pas accéléré par la mise en cache des seules dépendances : c'est un problème distinct, relevant plutôt d'outils comme Turborepo pour la mise en cache des résultats de build.
- Le cache n'élimine pas le besoin d'un fichier de verrouillage figé et commité : sans `composer.lock` ni `package-lock.json`, la clé de cache perd tout son sens.

## En résumé

Mettre en cache Composer et npm dans GitHub Actions demande une configuration courte mais précise, centrée sur une clé dérivée du fichier de verrouillage. Bien réglé, ce cache réduit nettement la durée des pipelines sans aucun risque d'installer une mauvaise version de dépendance, puisque les gestionnaires de paquets revérifient toujours l'intégrité du cache restauré par rapport au fichier de lock du projet.