Tous les packages téléchargés depuis le registre sont stockés dans un cache global à ~/.bun/install/cache, ou le chemin défini par la variable d'environnement BUN_INSTALL_CACHE_DIR. Ils sont stockés dans des sous-répertoires nommés comme ${name}@${version}, donc plusieurs versions d'un package peuvent être mises en cache.

Configuration du comportement du cache

[install.cache]
# le répertoire à utiliser pour le cache
dir = "~/.bun/install/cache"

# quand true, ne pas charger depuis le cache global.
# Bun peut toujours écrire dans node_modules/.cache
disable = false

# quand true, toujours résoudre les dernières versions depuis le registre
disableManifest = false

---

Minimiser les retéléchargements

Bun s'efforce d'éviter de retélécharger plusieurs fois les packages. Lors de l'installation d'un package, si le cache contient déjà une version dans la plage spécifiée par package.json, Bun utilisera le package mis en cache au lieu de le retélécharger.

Détails d'installation

Si la version semver a un suffixe pré-version (1.0.0-beta.0) ou un suffixe de build (1.0.0+20220101), il est remplacé par un hachage de cette valeur, pour réduire les risques d'erreurs associées aux longs chemins de fichiers.

Lorsque le dossier node_modules existe, avant d'installer, Bun vérifie que node_modules contient tous les packages attendus avec les versions appropriées. Si c'est le cas, bun install se termine. Bun utilise un analyseur JSON personnalisé qui s'arrête dès qu'il trouve "name" et "version".

Si un package est manquant ou a une version incompatible avec le package.json, Bun vérifie un module compatible dans le cache. S'il est trouvé, il est installé dans node_modules. Sinon, le package sera téléchargé depuis le registre puis installé.

---

Copie rapide

Une fois qu'un package est téléchargé dans le cache, Bun doit toujours copier ces fichiers dans node_modules. Bun utilise les appels système les plus rapides disponibles pour effectuer cette tâche. Sur Linux, il utilise des liens physiques (hardlinks) ; sur macOS, il utilise clonefile.

---

Économiser de l'espace disque

Puisque Bun utilise des liens physiques pour "copier" un module dans le répertoire node_modules d'un projet sur Linux et Windows, le contenu du package n'existe qu'à un seul emplacement sur le disque, réduisant considérablement la quantité d'espace disque dédiée à node_modules.

Cet avantage s'applique également à macOS, mais il y a des exceptions. Il utilise clonefile qui est copy-on-write, ce qui signifie qu'il n'occupera pas d'espace disque, mais il comptera vers la limite du lecteur. Ce comportement est utile si quelque chose tente de patcher node_modules/*, il est donc impossible d'affecter d'autres installations.

Stratégies d'installation

Ce comportement est configurable avec le drapeau --backend, qui est respecté par toutes les commandes de gestion de packages de Bun.

• hardlink : Par défaut sur Linux et Windows.
• clonefile : Par défaut sur macOS.
• clonefile_each_dir : Similaire à clonefile, sauf qu'il clone chaque fichier individuellement par répertoire. Il est uniquement disponible sur macOS et a tendance à être plus lent que clonefile.
• copyfile : Le repli utilisé lorsque l'un des ci-dessus échoue. C'est l'option la plus lente. Sur macOS, il utilise fcopyfile() ; sur Linux il utilise copy_file_range().
• symlink : Actuellement utilisé uniquement pour les dépendances file: (et éventuellement link:). Pour éviter les boucles infinies, il ignore la création de liens symboliques pour le dossier node_modules.

Si vous installez avec --backend=symlink, Node.js ne résoudra pas les node_modules des dépendances à moins que chaque dépendance ait son propre dossier node_modules ou que vous passiez --preserve-symlinks à node. Consultez la documentation Node.js sur --preserve-symlinks.

bun install --backend symlink
node --preserve-symlinks ./foo.js

Le runtime de Bun n'expose pas actuellement d'équivalent de --preserve-symlinks.