Bun soporta workspaces en package.json. Los espacios de trabajo facilitan desarrollar software complejo como un monorepo que consiste en varios paquetes independientes.

Es común que un monorepo tenga la siguiente estructura:

<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

En el package.json raíz, la clave "workspaces" se usa para indicar qué subdirectorios deben considerarse paquetes/espacios de trabajo dentro del monorepo. Es convencional colocar todos los espacios de trabajo en un directorio llamado packages.

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

NOTE

**Soporte de glob** — Bun soporta sintaxis de glob completa en `"workspaces"`, incluyendo patrones negativos (ej. `!**/excluded/**`). Ver [aquí](/es/runtime/glob#supported-glob-patterns) para una lista completa de sintaxis soportada.

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

Cada espacio de trabajo tiene su propio package.json. Al referenciar otros paquetes en el monorepo, se pueden usar semver o protocolos de espacio de trabajo (ej. workspace:*) como el campo de versión en tu package.json.

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

bun install instalará dependencias para todos los espacios de trabajo en el monorepo, eliminando duplicados de paquetes si es posible. Si solo quieres instalar dependencias para espacios de trabajo específicos, puedes usar la bandera --filter.

# Instalar dependencias para todos los espacios de trabajo que comienzan con `pkg-` excepto `pkg-c`
bun install --filter "pkg-*" --filter "!pkg-c"

# Las rutas también pueden usarse. Esto es equivalente al comando de arriba.
bun install --filter "./packages/pkg-*" --filter "!pkg-c" # o --filter "!./packages/pkg-c"

Al publicar, las versiones workspace: son reemplazadas por la versión del package.json del paquete,

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

Establecer una versión específica tiene precedencia sobre la versión del package.json del paquete,

"workspace:1.0.2" -> "1.0.2" // Incluso si la versión actual es 1.0.1

Los espacios de trabajo tienen un par de beneficios principales.

• El código puede dividirse en partes lógicas. Si un paquete depende de otro, simplemente puedes agregarlo como una dependencia en package.json. Si el paquete b depende de a, bun install instalará tu directorio local packages/a en node_modules en lugar de descargarlo desde el registro de npm.
• Las dependencias pueden eliminarse por duplicados. Si a y b comparten una dependencia común, será hoisted al directorio node_modules raíz. Esto reduce el uso redundante de disco y minimiza los problemas de "infierno de dependencias" asociados con tener múltiples versiones de un paquete instaladas simultáneamente.
• Ejecutar scripts en múltiples paquetes. Puedes usar la bandera --filter para ejecutar fácilmente scripts de package.json en múltiples paquetes en tu espacio de trabajo, o --workspaces para ejecutar scripts en todos los espacios de trabajo.

Compartir versiones con Catálogos

Cuando muchos paquetes necesitan las mismas versiones de dependencias, los catálogos te permiten definir esas versiones una vez en el package.json raíz y referenciarlas desde tus espacios de trabajo usando el protocolo catalog:. Actualizar el catálogo automáticamente actualiza cada paquete que lo referencia. Ver Catálogos para detalles.

NOTE

⚡️ **Velocidad** — Las instalaciones son rápidas, incluso para monorepos grandes. Bun instala el monorepo [Remix](https://github.com/remix-run/remix) en aproximadamente `500ms` en Linux.

• 28 veces más rápido que npm install
• 12 veces más rápido que yarn install (v1)
• 8 veces más rápido que pnpm install