Todos os pacotes baixados do registro são armazenados em um cache global em ~/.bun/install/cache, ou o caminho definido pela variável de ambiente BUN_INSTALL_CACHE_DIR. Eles são armazenados em subdiretórios nomeados como ${name}@${version}, para que várias versões de um pacote possam ser armazenadas em cache.

Configurando o comportamento do cache

[install.cache]
# o diretório a ser usado para o cache
dir = "~/.bun/install/cache"

# quando true, não carregar do cache global.
# O Bun ainda pode gravar em node_modules/.cache
disable = false

# quando true, sempre resolver as versões mais recentes do registro
disableManifest = false

---

Minimizando novos downloads

O Bun se esforça para evitar baixar pacotes várias vezes. Ao instalar um pacote, se o cache já contiver uma versão no intervalo especificado pelo package.json, o Bun usará o pacote em cache em vez de baixá-lo novamente.

Detalhes da instalação

Se a versão semver tiver sufixo de pré-lançamento (1.0.0-beta.0) ou um sufixo de build (1.0.0+20220101), ele será substituído por um hash desse valor, para reduzir as chances de erros associados a caminhos de arquivo longos.

Quando a pasta node_modules existe, antes de instalar, o Bun verifica se node_modules contém todos os pacotes esperados com versões apropriadas. Se sim, bun install é concluído. O Bun usa um analisador JSON personalizado que para de analisar assim que encontra "name" e "version".

Se um pacote estiver faltando ou tiver uma versão incompatível com o package.json, o Bun verifica se há um módulo compatível no cache. Se encontrado, ele é instalado em node_modules. Caso contrário, o pacote será baixado do registro e então instalado.

---

Cópia rápida

Uma vez que um pacote é baixado para o cache, o Bun ainda precisa copiar esses arquivos para node_modules. O Bun usa as syscalls mais rápidas disponíveis para executar esta tarefa. No Linux, usa hardlinks; no macOS, usa clonefile.

---

Economizando espaço em disco

Como o Bun usa hardlinks para "copiar" um módulo para o diretório node_modules de um projeto no Linux e Windows, o conteúdo do pacote existe apenas em um único local no disco, reduzindo muito a quantidade de espaço em disco dedicado ao node_modules.

Este benefício também se aplica ao macOS, mas há exceções. Ele usa clonefile que é copy-on-write, o que significa que não ocupará espaço em disco, mas contará para o limite da unidade. Este comportamento é útil se algo tentar corrigir node_modules/*, então é impossível afetar outras instalações.

Estratégias de instalação

Este comportamento é configurável com a flag --backend, que é respeitada por todos os comandos de gerenciamento de pacotes do Bun.

• hardlink: Padrão no Linux e Windows.
• clonefile: Padrão no macOS.
• clonefile_each_dir: Similar ao clonefile, exceto que clona cada arquivo individualmente por diretório. Está disponível apenas no macOS e tende a ser mais lento que clonefile.
• copyfile: O fallback usado quando qualquer um dos acima falha. É a opção mais lenta. No macOS, usa fcopyfile(); no Linux usa copy_file_range().
• symlink: Atualmente usado apenas para dependências file: (e eventualmente link:). Para prevenir loops infinitos, ele ignora a criação de link simbólico na pasta node_modules.

Se você instalar com --backend=symlink, o Node.js não resolverá node_modules de dependências a menos que cada dependência tenha sua própria pasta node_modules ou você passe --preserve-symlinks para node. Veja documentação do Node.js sobre --preserve-symlinks.

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

O runtime do Bun não expõe atualmente um equivalente de --preserve-symlinks.