2026 Frontend-Runtime-Auswahl:
Bun, Node.js 24 & Deno auf Remote Mac — Build-Geschwindigkeit, Lockfiles & Spiegel

Apple-Silicon-Remote-Mac-Knoten liegen oft günstig zu VPN oder CI-Region, sind aber weiterhin geteilte Maschinen: kalte Caches, parallele Jobs und wechselnde Last verändern die Wanduhr messbar. Jede Schlagzeile „Runtime X ist dreimal schneller“ gilt nur unter definierbarem Netzpfad, Spiegel-Gesundheit und dem Zustand von node_modules. Für Web-Teams zählt deshalb Reproduzierbarkeit vor Spitzen-Speed: Runtime pinnen, genau ein autoritatives Lockfile committen und Registry-Endpunkte so dokumentieren wie die Node-Version.

Messen Sie fair: node_modules und relevante Caches leeren, CPU-Last stabilisieren, mehrere Läufe protokollieren und dabei Spiegel-Host plus Lockfile-Hash notieren. In Monorepos gehören pnpm-Store und Turbo-Cache in die gleiche Geschichte — siehe pnpm, Turborepo und Registry-Spiegel auf Remote Mac. Für strikte Node-Layouts pro Repo: Node/npm-Versionen und Multi-Projekt-Isolation.

Schritt 1 — Runtime und Lockfile pinnen. Pro Package Manager genau ein autoritatives Lockfile im Repository führen. Auf dem Remote Mac vor install dieselbe Major-Runtime wie in der CI laden (Node 24, feste Bun-Release-Zeile oder fixe Deno-Version). Jede Diskrepanz hier verwischt jeden Geschwindigkeitsvorteil.

Schritt 2 — Registry-Spiegel und Cache-Verzeichnisse. Spiegel-URL und Cache-Roots aus CI-Geheimnissen oder Shell-Profilen exportieren — nicht nur in einem lokalen ~/.npmrc. pnpm-store-dir mit der Monorepo-Spiegel-Checkliste abstimmen; bei Bun bei HTTPS-Inspection Unternehmens-Root-Zertifikate hinterlegen.

Schritt 3 — Build-Parität prüfen. Denselben Produktions-build wie in der Pipeline ausführen; Vite-Ausgabe oder Bundle-Statistiken einmal pro Release-Zug zwischen Laptop und Remote vergleichen. Details: Vite/Webpack-Build-Cache und Deploy plus Safari-Verifikation.

Vite läuft unter alternativen Runtimes oft, aber Plugins, die Kindprozesse starten oder native Binaries nachladen, setzen weiterhin Node voraus; SSR-Adapter brechen typischerweise zuerst. Pragmatisches Team-Modell: Release-Builds auf Node 24 standardisieren, Bun in Feature-Branches testen, bis postinstall, Unit- und E2E grün sind, und Deno nur dort einsetzen, wo deno.json-Tasks bereits die Quelle der Wahrheit sind — ohne stilles Mischen von PATH zwischen Projekten auf demselben Host.

Wer npm run build durch bun run build ersetzt, sollte in der CI dieselbe Substitution fahren und die Lockfile-Generierung (npm vs. bun) im Review erklären. Supply-Chain-Themen (Audit, Spiegel) ergänzen Sie mit npm/pnpm-Audit auf Remote Mac.

Nur ausführen, wenn Sie den Host betreiben oder explizite Operator-Freigabe haben. Die Befehle löschen lokale Caches und Projekt-Artefakte.

A. Projektspezifische Runtime-Isolation

# Node: z. B. fnm (nvm analog)
fnm install 24
fnm use 24
node -v

# Bun: Version im Installer anpassen
curl -fsSL https://bun.sh/install | bash
~/.bun/bin/bun --version

# Deno: Standard-Installationspfad
curl -fsSL https://deno.land/install.sh | sh
deno --version

# Gemischte Globals vermeiden
npm config delete prefix 2>/dev/null || true
pnpm config get store-dir

B. Speicher zurückgewinnen: npm / pnpm / Yarn

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

# Im Repo-Root (zerstörerisch)
rm -rf node_modules .vite dist build .turbo .next .nuxt

C. Bun- und Deno-Caches

rm -rf ~/.bun/install/cache 2>/dev/null || true
# Optional: Deno-Modul neu ziehen
# deno cache --reload ./src/main.ts
rm -rf ~/Library/Caches/deno 2>/dev/null || true

Anschließend mit dem CI-Spiegel und committiertem Lockfile neu installieren; pnpm install --frozen-lockfile (oder npm-/Yarn-Äquivalent) bestätigt einen sauberen Abhängigkeitsgraphen.