2026 Checklist pièges front-end :
Rspack vs esbuild sur Mac distant — cache, démarrage à froid et workers
Sur un Mac distant loué, une mauvaise politique de bundler se paie deux fois : en minutes murales perdues, puis en CI instable lorsque les caches se télescopent. Cette checklist oppose Rspack (graphe de type webpack + cache filesystem) à esbuild (parallélisme Go, vitesse en passe unique), nomme des chemins et variables d’environnement prêts à l’emploi, et se conclut par une porte d’acceptation en trois étapes avant livraison. Croisez-la avec notre guide optimisation cache Vite et Webpack et la checklist monorepo pnpm, Turborepo et miroir npm pour aligner clés de tâches et couches bundler.
01 Scénario et référence
Imaginez un monorepo volumineux ou un workspace multi-paquets exécuté sur un runner Mac distant : les installations reposent sur APFS, les builds rivalisent avec sshd et parfois une session graphique distante, et la CI restaure des archives ou de l’objet stocké pour node_modules et les caches d’outils. Votre ligne de base doit distinguer le démarrage à froid (aucun cache bundler, ou premier run après clone) du scénario incrémental (second build de production sur le même commit avec cache intact).
Consignez quatre mesures par chaîne d’outils : temps mural à froid, temps mural à chaud, pic de mémoire résidente (RSS) et volume total des caches sur disque. Joignez le SHA git, le hash du lockfile et les versions exactes de node -v, Rspack et esbuild. Sans ce quadruplet, « c’est rapide sur ma branche » ne survit pas à la fusion. Pour les pipelines CSS et PostCSS gourmands, croisez d’abord la matrice mémoire Tailwind v4 / PostCSS sur Mac distant avant d’imputer les lenteurs au seul bundler.
Enfin, documentez la charge concurrente (autres jobs sur la même machine, sessions utilisateur) au moment des mesures : sur Mac partagé, la variance inter-run dépasse souvent celle observée sur un poste dédié.
02 Limites d’adéquation : Rspack vs esbuild
Rspack cible les équipes en migration depuis webpack : loaders, splitChunks, schémas proches de la fédération de modules, et un cache filesystem qui survit aux redémarrages de processus lorsqu’il est correctement configuré. C’est le choix par défaut lorsque le graphe est énorme, très personnalisé, et que vous avez besoin de rebuilds incrémentaux sur plusieurs jours sur le même disque de workspace.
esbuild brille lorsque vous voulez peu de configuration et un débit maximal en une passe : bibliothèques, paquets internes, ou pipelines qui invoquent l’API ou la CLI pour transpiler et bundler. Il n’offre pas un cache de modules persistant de niveau webpack ; la vitesse vient du parallélisme agressif et d’une implémentation compacte. L’usage mixte est courant : esbuild pour des paquets ciblés, Rspack pour la coque applicative qui exige la profondeur des loaders.
| Dimension | Privilégier Rspack | Privilégier esbuild |
|---|---|---|
| Profondeur loaders / plugins | Loaders lourds, graphe d’actifs hérité | Surtout TS/JS, JSON, plugins limités |
| Objectif de persistance | Workspaces chauds sur plusieurs jours ; restauration cache CI | Étapes CI éphémères ; vitesse sans cache longue durée au cœur du bundler |
| Maîtrise opérationnelle | Équipes déjà à l’aise avec webpack | Équipes qui minimisent la surface de config |
03 Tableau : démarrage à froid et builds incrémentaux
Le tableau suivant résume les critères d’acceptation. Ajustez les chemins à votre arborescence ; conservez une racine de cache par version majeure d’outil pour éviter de désérialiser des blobs incompatibles après restauration.
| Sujet | Rspack (forme webpack) | esbuild |
|---|---|---|
| Profil à froid | Premier build après purge cache ; paie compilation du graphe et lectures modules | Souvent le plus rapide à froid parmi les bundlers Node ; reste limité par le disque sur de très gros arbres d’entrées |
| Profil incrémental | Fort lorsque cache.type: 'filesystem' est activé et correctement cléé |
Gain incrémental souvent via l’orchestrateur ou le graphe de tâches monorepo, pas un cache de modules type webpack au cœur |
| Répertoire de cache typique | node_modules/.cache/rspack ou cache.cacheDirectory explicite (ex. .rspack-cache à la racine) |
Pas de cache module first-party ; persistance des sorties ou cache de tâches amont (Turborepo, Nx) |
| Interrupteur cache persistant | cache: { type: 'filesystem', buildDependencies: { config: [__filename] } } dans rspack.config |
Sans équivalent natif au cœur ; persistance au niveau CI ou artefacts |
| Parallélisme / workers | Processus Node ; limitez les étapes lourdes concurrentes ; patterns hérités du thread-loader webpack |
GOMAXPROCS=<n> pour plafonner le fan-out Go (ex. export GOMAXPROCS=6) |
| Tas Node et pool de threads | NODE_OPTIONS=--max-old-space-size=8192 (augmenter si OOM RSS) ; optionnel UV_THREADPOOL_SIZE=16 pour addons natifs très I/O |
Pas de tas Node pour le cœur Go ; gardez un GOMAXPROCS conservateur lorsque Node enveloppe esbuild |
export NODE_OPTIONS="--max-old-space-size=8192"
export UV_THREADPOOL_SIZE=16
export GOMAXPROCS=6Ajustez le tas et GOMAXPROCS à votre hôte : sur une machine « huit cœurs performance », réserver un ou deux cœurs à macOS et SSH stabilise souvent la latence de queue.
04 Seuils disque et mémoire sur Mac distant
Traitez disque et RAM comme partie du contrat bundler. Les caches filesystem grossissent avec le nombre de modules et le niveau des source maps ; les bureaux distants consomment aussi de la marge pour Spotlight, métadonnées Time Machine et sessions utilisateur.
| Signal | Seuil prudent | Action |
|---|---|---|
| Espace libre après restauration | Au moins 25 Go pour monorepos moyens ; 40 Go si vous conservez plusieurs générations de cache | Purger d’anciens dossiers .rspack-cache ; dédupliquer les clés CI ; éviter des node_modules dupliqués |
| Croissance du répertoire cache | Alerte si la croissance hebdomadaire dépasse 20 % sans changement de dépendances | Invalider sur changement de hash de config ; auditer source maps et copies d’actifs |
| Pic RSS pendant le build | Rester sous environ RAM − 8 Go sur hôtes partagés 24–36 Go | Réduire le parallélisme, scinder les paquets ou fragmenter les jobs CI |
| Pression swap | Swap soutenu > 2 Go pendant la compilation | Sérialiser Rspack et esbuild ou lancer les jobs lourds l’un après l’autre |
05 Acceptation en trois étapes avant publication et FAQ
Étape 1 — Vérité à froid : depuis un état de cache propre sur le SHA de release, exécutez une fois le build de production et archivez le journal. Si le temps à froid régresse de plus de quinze pour cent par rapport à la dernière release verte sans bump majeur de dépendances, stoppez et diff la config.
Étape 2 — Contrat à chaud : le second build immédiat doit réduire nettement le temps mural (cible typique : au moins vingt-cinq à quarante pour cent vs froid pour Rspack avec cache filesystem). Si le chaud n’est pas plus rapide, le chemin de cache est faux, les clés trop agressives, ou un scan type antivirus martèle le répertoire de cache.
Étape 3 — Courtoisie hôte partagé : avec GOMAXPROCS et le parallélisme Node plafonnés, vérifiez que la latence interactive SSH reste acceptable pendant le build. Ne promouvez qu’après succès des trois étapes.
Q : Dois-je placer le cache Rspack sur NFS ou un volume réseau ?
R : Préférez l’APFS local sur le Mac distant ; la latence réseau annule les gains du cache filesystem.
Q : Un job ou deux pour Rspack + esbuild ?
R : Si le RSS combiné approche votre seuil, sérialisez ou fragmentez par graphe de paquets ; parallélisez seulement si la télémétrie mémoire le permet.
Q : Où Turborepo et le cache Rspack interagissent-ils ?
R : Turbo met en cache les sorties de tâches ; Rspack met en cache le travail de graphe de modules dans la tâche bundler. Cléez les deux avec hash de lockfile et de config pour aligner les hits de cache distant.
Choisissez Rspack lorsque vous avez besoin de graphes de profondeur webpack et d’un cache filesystem restaurable en CI ; choisissez esbuild pour la vitesse en passe unique en acceptant la stratégie de cache à la couche d’orchestration. Instrumentez froid vs chaud, protégez les marges disque et RAM sur les hôtes Mac distant, et ne livrez qu’après passage de la porte en trois étapes.
Lorsque vous voulez exécuter ces builds sur du Apple Silicon dédié, ouvrez l’accueil MacWww, consultez les tarifs et offres pour une location transparente, et parcourez le centre d’aide (SSH, console, automatisation). Poursuivez avec l’index du blog front-end et DevOps pour des checklists voisines.
Si votre équipe a besoin de runners macOS prévisibles pour les pipelines Rspack et esbuild, achetez ou réservez une capacité via MacWww afin que les démarrages à froid s’effectuent sur des workspaces NVMe locaux plutôt que sur des VM surchargées.
Rspack et esbuild sur Mac loué
Caches APFS locaux, vrais cœurs pour régler GOMAXPROCS, marge pour les installs monorepo. Parcourez l’accueil, comparez les tarifs, puis suivez la documentation d’aide pour brancher votre runner CI.