2026 CI Mac distant : Yarn Berry — PnP ou node_modules, miroir de registry et installation concurrente

Sous un RTT élevé vers npmjs ou un registre privé, le goulot quitte souvent le CPU du Mac M4 pour devenir séquentiel-réseau : résolution, téléchargement des archives, vérification des checksums. Le PnP évite la copie massive de milliers de petits fichiers sur APFS, ce qui compresse le temps « disque » après fetch, mais ne réduit pas magiquement les allers-retours HTTP si le miroir de registry est mal placé. node_modules matérialise chaque paquet : plus d’I/O locale et d’inodes, parfois plus simple pour des outils legacy qui supposent une résolution classique, au prix d’une phase d’extraction plus longue dès que le cache Yarn global n’est pas chaud.

Sur un CI Mac distant partagé, mesurez toujours trois chronos distincts : fetch réseau, link / matérialisation, post-install scripts. Les équipes hybrides front + iOS gagnent à colocaliser le runner avec le miroir approuvé par la sécurité plutôt qu’à pousser aveuglément networkConcurrency au maximum — sinon les 429 du registre masquent la différence PnP vs classique.

En 2026, les images CI officielles poussent Node 22 LTS comme socle par défaut sur arm64 : le gain attendu est surtout côté exécution des scripts et de la pile HTTP du runtime, pas sur la magie du gestionnaire de paquets. Traitez donc le choix PnP / node_modules comme une décision d’architecture de dépôt — versionnée, testée sur un runner identique à la prod CI — plutôt que comme un simple toggle sur une recette Docker.

Figez la ligne Yarn Berry via Corepack dans l’image CI (corepack enable puis corepack prepare yarn@stable --activate ou la version exacte du dépôt). Le bloc suivant illustre un socle immutable, un miroir de registry d’entreprise et des bornes réseau — adaptez les URL et secrets injectés par votre coffre.

# .yarnrc.yml (extrait — ne committez pas les secrets en clair)
nodeLinker: pnp          # ou: node-modules
enableGlobalCache: true
compressionLevel: mixed    # compromis CPU réseau sur Apple Silicon
enableImmutableInstalls: true
checksumBehavior: throw

npmRegistryServer: "https://registry.npmmirror.com/"   # exemple de miroir ; validez la politique sécurité
unsafeHttpWhitelist: []   # laissez vide si tout est HTTPS

# Limites réseau typiques CI transfrontalier (ajuster après mesure)
httpTimeout: 120000
httpRetry: 3
networkConcurrency: 12   # baisser à 8 si 429 fréquents

plugins:
  - path: .yarn/plugins/@yarnpkg/plugin-workspace-tools.cjs
    spec: "@yarnpkg/plugin-workspace-tools"

Pour une installation concurrente maîtrisée, corrélez networkConcurrency avec la bande passante sortante du runner et la limite du miroir ; sur un pool Mac distant mutualisé, deux jobs agressifs peuvent se priver mutuellement de débit bien avant la saturation CPU. Activez yarn config -v en phase de debug ponctuel, jamais en boucle sur des secrets.

1. Verrou Yarn : champ packageManager dans la racine package.json + même digest Corepack sur chaque runner.
2. Miroir documenté : propriétaire, SLA, procédure de rollback si le miroir diverge de npmjs.
3. Cache CI : répertoire YARN_CACHE_FOLDER sur disque local NVMe, pas sur un volume SMB transfrontalier.
4. Hooks postinstall listés et bornés (timeout explicite, pas de téléchargements non déterministes).
5. Politique checksumBehavior alignée avec la gouvernance SBOM (throw vs update).

Les monorepos d’entreprise mélangent souvent des scopes publics (lodash) et des paquets internes (@acme/sdk) derrière GitHub Packages. Séparez deux identités : un NPM_TOKEN lecture seule pour npmjs (ou votre proxy) et un GITHUB_TOKEN / PAT read:packages minimal pour les scopes GitHub, sans réutiliser le même secret sur les deux registres si la politique d’audit l’interdit.

# .yarnrc.yml — scopes (exemple)
npmScopes:
  acme:
    npmRegistryServer: "https://npm.pkg.github.com"
    npmAlwaysAuth: true
# Injectez npmAuthToken via variable d'environnement au runtime CI :
# export YARN_NPM_AUTH_TOKEN=...   # token npmjs / proxy
# export YARN_NPM_AUTH_TOKEN_3F6B6477=...  # hash scope GitHub (yarn npm login)

Rotation : planifiez la rotation des PAT sur un rythme plus court que la durée de vie du plus long pipeline ; double écriture temporaire dans le coffre (ancien + nouveau jeton) le temps de purger les caches runner. Journalisez uniquement les huit derniers caractères du fingerprint secret pour le corrélationnel, jamais la valeur. Pour un autre angle « artefacts privés et couches », croisez avec la matrice Conan 2 et remotes déjà publiée sur ce blog.

Sur Apple Silicon, la RAM est souvent le premier plafond lorsque plusieurs workspaces yarn workspaces foreach tournent en parallèle. Gardez une marge pour Xcode ou Metro dans la même file d’attente job si vous mutualisez l’hôte. Côté stockage, réutilisez l’échelle déjà éprouvée sur MacPull : alertes 80 % / 85 % / 90 % d’occupation du volume cache ; au-delà, purgez le cache Yarn le moins récemment utilisé avant d’accepter de nouveaux jobs « froids ».

Évitez d’empiler maxWorkers Jest, builds Vite et yarn install sans plafond sur un même nœud : le scheduler GitHub Actions ou GitLab ne connaît pas votre pression disque interne — seule votre sonde le voit.

Enrobez yarn install --immutable avec trois à quatre tentatives et backoff 2 s → 4 s → 8 s uniquement pour les erreurs transport (reset TCP, TLS handshake, 5xx du miroir). Si la deuxième tentative modifie le lockfile, considérez un incident de supply-chain ou de version Yarn — pas un simple glitch.

Acceptation CI : après install, exécutez yarn dedupe --check si votre politique l’exige, puis une cible no-op sur un sous-ensemble de workspaces (avec les drapeaux yarn workspaces foreach exigés par votre ligne Yarn 3/4, par ex. portée --all ou --since) pour détecter les résolutions incohérentes. Comparez le digest du yarn.lock (ou yarn.lock + .yarn/cache en mode zero-install si vous l’utilisez) avec l’artefact attendu du dernier merge sur main.

Le PnP casse-t-il encore les résolveurs natifs iOS ? En 2026 la situation s’est normalisée pour TypeScript et Metro lorsque les équipes appliquent les intégrations documentées ; restez sur node-modules si un outillage critique impose encore des chemins physiques non patchables à court terme.

Faut-il committer le cache Yarn (zero-install) sur un runner distant ? Possible pour la vitesse, rare pour la taille du dépôt ; la plupart des équipes préfèrent un cache CI chiffré et des installs immutables depuis yarn.lock.

Comment tester un nouveau miroir sans bloquer la production ? Branchez un job canary sur une branche jetable avec le même yarn.lock, comparez les checksums résolus et la latence P95 avant de basculer la variable d’environnement globale.

Corepack est-il obligatoire avec Node 22 ? Fortement recommandé pour aligner développeurs et CI ; documentez la version Yarn exacte à côté de la version Node dans le README mainteneur.