Skip to content

Bun prend en charge workspaces dans package.json. Les workspaces facilitent le développement de logiciels complexes en tant que monorepo composé de plusieurs packages indépendants.

Il est courant qu'un monorepo ait la structure suivante :

txt
<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

Dans le package.json racine, la clé "workspaces" est utilisée pour indiquer quels sous-répertoires doivent être considérés comme des packages/workspaces dans le monorepo. Il est conventionnel de placer tous les workspaces dans un répertoire appelé packages.

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

NOTE

**Prise en charge des glob** — Bun prend en charge la syntaxe glob complète dans `"workspaces"`, y compris les motifs négatifs (par ex. `!**/excluded/**`). Consultez [ici](/fr/runtime/glob#supported-glob-patterns) pour une liste complète de la syntaxe prise en charge.
json
{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
}

Chaque workspace a son propre package.json. Lors de la référence d'autres packages dans le monorepo, les versions semver ou les protocoles workspace (par ex. workspace:*) peuvent être utilisés comme champ de version dans votre package.json.

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

bun install installera les dépendances pour tous les workspaces dans le monorepo, en dédupliquant les packages si possible. Si vous souhaitez uniquement installer des dépendances pour des workspaces spécifiques, vous pouvez utiliser le drapeau --filter.

bash
# Installer les dépendances pour tous les workspaces commençant par `pkg-` sauf pour `pkg-c`
bun install --filter "pkg-*" --filter "!pkg-c"

# Les chemins peuvent également être utilisés. Ceci est équivalent à la commande ci-dessus.
bun install --filter "./packages/pkg-*" --filter "!pkg-c" # ou --filter "!./packages/pkg-c"

Lors de la publication, les versions workspace: sont remplacées par la version du package.json du package,

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

Définir une version spécifique prend le pas sur la version du package.json du package,

"workspace:1.0.2" -> "1.0.2" // Même si la version actuelle est 1.0.1

Les workspaces ont quelques avantages majeurs.

  • Le code peut être divisé en parties logiques. Si un package dépend d'un autre, vous pouvez simplement l'ajouter comme dépendance dans package.json. Si le package b dépend de a, bun install installera votre répertoire local packages/a dans node_modules au lieu de le télécharger depuis le registre npm.
  • Les dépendances peuvent être dédupliquées. Si a et b partagent une dépendance commune, elle sera hoisted vers le répertoire node_modules racine. Cela réduit l'utilisation redondante du disque et minimise les problèmes de "dependency hell" associés à l'installation simultanée de plusieurs versions d'un package.
  • Exécuter des scripts dans plusieurs packages. Vous pouvez utiliser le drapeau --filter pour exécuter facilement des scripts package.json dans plusieurs packages de votre workspace, ou --workspaces pour exécuter des scripts dans tous les workspaces.

Partager des versions avec les catalogues

Lorsque de nombreux packages ont besoin des mêmes versions de dépendances, les catalogues vous permettent de définir ces versions une fois dans le package.json racine et de les référencer depuis vos workspaces en utilisant le protocole catalog:. La mise à jour du catalogue met automatiquement à jour chaque package qui le référence. Consultez Catalogues pour plus de détails.

NOTE

⚡️ **Vitesse** — Les installations sont rapides, même pour les grands monorepos. Bun installe le monorepo [Remix](https://github.com/remix-run/remix) en environ `500ms` sur Linux.
  • 28 fois plus rapide que npm install
  • 12 fois plus rapide que yarn install (v1)
  • 8 fois plus rapide que pnpm install

Bun édité par www.bunjs.com.cn