Bun supporta workspaces in package.json. I workspace rendono facile sviluppare software complessi come un monorepo costituito da diversi pacchetti indipendenti.

È comune per un monorepo avere la seguente struttura:

<root>
├── README.md
├── bun.lock
├── package.json
├── tsconfig.json
└── packages
    ├── pkg-a
    │   ├── index.ts
    │   ├── package.json
    │   └── tsconfig.json
    ├── pkg-b
    │   ├── index.ts
    │   ├── package.json
    │   └── tsconfig.json
    └── pkg-c
        ├── index.ts
        ├── package.json
        └── tsconfig.json

Nel package.json radice, la chiave "workspaces" è usata per indicare quali sottodirectory dovrebbero essere considerate pacchetti/workspace all'interno del monorepo. È convenzionale posizionare tutti i workspace in una directory chiamata packages.

{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/*"],
  "devDependencies": {
    "example-package-in-monorepo": "workspace:*"
  }
}

NOTE

**Supporto glob** — Bun supporta la sintassi glob completa in `"workspaces"`, inclusi pattern negativi (ad es. `!**/excluded/**`). Vedi [qui](/it/runtime/glob#supported-glob-patterns) per un elenco completo della sintassi supportata.

{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
}

Ogni workspace ha il proprio package.json. Quando si riferisce ad altri pacchetti nel monorepo, il semver o i protocolli workspace (ad es. workspace:*) possono essere usati come campo versione nel tuo package.json.

{
  "name": "pkg-a",
  "version": "1.0.0",
  "dependencies": {
    "pkg-b": "workspace:*"
  }
}

bun install installerà le dipendenze per tutti i workspace nel monorepo, deduplicando i pacchetti se possibile. Se vuoi installare le dipendenze solo per workspace specifici, puoi usare il flag --filter.

# Installa dipendenze per tutti gli workspace che iniziano con `pkg-` tranne `pkg-c`
bun install --filter "pkg-*" --filter "!pkg-c"

# Anche i percorsi possono essere usati. Questo è equivalente al comando sopra.
bun install --filter "./packages/pkg-*" --filter "!pkg-c" # o --filter "!./packages/pkg-c"

Durante la pubblicazione, le versioni workspace: vengono sostituite dalla versione del package.json del pacchetto,

"workspace:*" -> "1.0.1"
"workspace:^" -> "^1.0.1"
"workspace:~" -> "~1.0.1"

Impostare una versione specifica ha la precedenza sulla versione del package.json del pacchetto,

"workspace:1.0.2" -> "1.0.2" // Anche se la versione corrente è 1.0.1

I workspace hanno un paio di benefici principali.

• Il codice può essere diviso in parti logiche. Se un pacchetto dipende da un altro, puoi semplicemente aggiungerlo come dipendenza in package.json. Se il pacchetto b dipende da a, bun install installerà la tua directory locale packages/a in node_modules invece di scaricarla dal registro npm.
• Le dipendenze possono essere deduplicate. Se a e b condividono una dipendenza comune, verrà hoisted alla directory node_modules radice. Questo riduce l'uso ridondante del disco e minimizza i problemi di "dependency hell" associati all'avere più versioni di un pacchetto installate simultaneamente.
• Eseguire script in più pacchetti. Puoi usare il flag --filter per eseguire facilmente script package.json in più pacchetti nel tuo workspace, o --workspaces per eseguire script in tutti i workspace.

Condividere versioni con i Cataloghi

Quando molti pacchetti necessitano delle stesse versioni di dipendenze, i cataloghi ti permettono di definire quelle versioni una volta nel package.json radice e riferirle dai tuoi workspace usando il protocollo catalog:. Aggiornare il catalogo aggiorna automaticamente ogni pacchetto che lo riferisce. Vedi Cataloghi per i dettagli.

NOTE

⚡️ **Velocità** — Le installazioni sono veloci, anche per grandi monorepo. Bun installa il monorepo [Remix](https://github.com/remix-run/remix) in circa `500ms` su Linux.

• 28 volte più veloce di npm install
• 12 volte più veloce di yarn install (v1)
• 8 volte più veloce di pnpm install