2026 Runtime front-end sur Mac distant :
Bun, Node.js 24 et Deno — installation, lockfile, miroir npm et build (cache en 3 étapes)

Un Mac distant Apple Silicon peut être géographiquement proche de votre VPN ou de la région CI, il reste souvent une machine partagée : caches froids, disques saturés et builds concurrents modifient le temps réel. Traitez tout slogan du type « X est trois fois plus rapide » comme conditionnel au chemin réseau, à l’état du miroir et à la présence d’un node_modules déjà chaud. En ingénierie front-end, la reproductibilité prime sur le pic de vitesse : figez le runtime, versionnez le lockfile et documentez l’URL du registre comme vous documentez la version de Node.

Pour comparer honnêtement, supprimez node_modules et les caches pertinents, stabilisez la charge CPU, enchaînez plusieurs essais et journalisez pour chaque mesure l’hôte du miroir et l’empreinte du lockfile. Les monorepos et le cache Turborepo distant se discutent en détail dans notre article pnpm, Turborepo et miroirs npm sur Mac distant. Pour structurer plusieurs versions de Node par dépôt, voir isolation multi-projets Node/npm sur Mac distant.

Les lignes résument les sujets typiques de l’ingénierie Web front-end en 2026, pas l’intégralité des cas limites. Validez toujours avec vos scripts package.json et vos dépendances binaires ou natives.

Étape 1 — Runtime et lockfile. Un seul lockfile faisant foi par gestionnaire de paquets. Sur le Mac distant, chargez la même ligne majeure de runtime que votre CI (Node 24, ligne de release Bun ou version Deno figée) avant toute commande install. Un décalage ici annule tout gain mesuré sur la durée d’installation.

Étape 2 — Miroir et répertoires de cache. Exportez l’URL du miroir et les racines de cache depuis les secrets CI ou les profils shell — pas uniquement depuis un .npmrc « ordinateur portable ». Alignez le store-dir pnpm comme dans la checklist monorepo ; pour Bun, validez les racines TLS si inspection HTTPS. Pour Deno, fixez DENO_DIR ou documentez le cache utilisateur afin d’éviter les mélanges entre projets.

Étape 3 — Parité de build. Exécutez le même script build de production ; comparez une fois par train les sorties ou les statistiques Vite entre poste local et Mac loué. Enchaînez avec optimisation cache Vite/Webpack et déploiement + vérification Safari en trois étapes pour fermer la boucle qualité.

Vite tourne souvent sous des runtimes alternatifs, mais les plugins qui lancent des processus fils ou téléchargent des binaires présupposent encore Node ; les adaptateurs SSR cassent en premier. En release, standardisez sur Node 24, expérimentez Bun sur une branche dédiée jusqu’à ce que postinstall et E2E soient verts, et réservez Deno aux dépôts qui orchestrent déjà tout via deno.json — sans mélanger silencieusement les entrées PATH entre sessions SSH.

Si vous automatisez la pré-livraison (smoke, Lighthouse), croisez ce guide avec scripts package.json et pré-livraison OpenClaw pour garder la même sémantique de commandes quel que soit le runtime sous-jacent.

N’exécutez ces opérations sur un Mac distant partagé qu’avec l’accord de l’opérateur : elles détruisent des caches locaux et des artefacts de build.

A. Isolation du runtime par projet

# Node : fnm ou nvm — exemple fnm
fnm install 24
fnm use 24
node -v

# Bun : version épinglée dans le préfixe utilisateur (adapter la version)
curl -fsSL https://bun.sh/install | bash
~/.bun/bin/bun --version

# Deno : script d’installation versionné
curl -fsSL https://deno.land/install.sh | sh
deno --version

# Dans chaque dépôt : éviter les globaux mélangés
npm config delete prefix 2>/dev/null || true
pnpm config get store-dir

B. Récupérer de l’espace : npm / pnpm / Yarn

npm cache verify
npm cache clean --force
pnpm store prune
yarn cache clean

# Artefacts de dépôt (à lancer à la racine du projet)
rm -rf node_modules .vite dist build .turbo .next .nuxt

C. Caches Bun et Deno

rm -rf ~/.bun/install/cache 2>/dev/null || true
# Option : forcer le re-téléchargement pour une entrée Deno
# deno cache --reload ./src/main.ts
rm -rf ~/Library/Caches/deno 2>/dev/null || true

Réinstallez avec le miroir et le lockfile de la CI ; utilisez pnpm install --frozen-lockfile (ou l’équivalent npm/yarn) pour prouver un graphe propre après purge.