Bun vs Deno
Bun (runtime en Zig, 3 veces más rápido) frente a Deno (runtime en Rust, TypeScript de serie) — comparativa de alternativas modernas a Node.js. Rendimiento, compatibilidad y ecosistema.
Almacén direccionable por contenido, aislamiento estricto, auditoría madura de la cadena de suministro
Núcleo en Rust, rápido, el componente de instalación del runtime Bun todo-en-uno
No hay un ganador absoluto; las dos herramientas optimizan para prioridades distintas. Si quieres mantenerte independiente del runtime y auditar la política en cada comando que modifica el lockfile, elige pnpm. Si ya usas Bun como runtime y la ganancia de disco/velocidad del almacén virtual global es crítica, bun install resulta atractivo. Ambas bloquean postinstall por defecto; la diferencia está en dónde colocan los puntos de auditoría. No mezcles las dos en el mismo repositorio — un solo lockfile, una sola fuente de verdad.
| Categoría | pnpm | bun install |
|---|---|---|
| Rendimiento | 8/10 | 9/10 |
| Facilidad de aprendizaje | 7/10 | 8/10 |
| Ecosistema | 9/10 | 6/10 |
| Comunidad | 8/10 | 7/10 |
| Mercado laboral | 7/10 | 6/10 |
| A prueba de futuro | 8/10 | 8/10 |
// pnpm 12.3 — instalación auditada y filtrado de workspace con allowBuilds
// package.json (raíz)
{
"name": "monorepo-root",
"private": true,
"packageManager": "[email protected]"
}
// pnpm-workspace.yaml — allowBuilds llegó en v10.26.0; v11 eliminó los nombres antiguos (onlyBuiltDependencies, etc.)
packages:
- "apps/*"
- "packages/*"
allowBuilds:
esbuild: true
sharp: true
core-js: false
catalog:
react: ^19.2.3
typescript: ^5.7.0
// Paso de instalación en CI (GitHub Actions)
- name: Install dependencies
run: pnpm install --frozen-lockfile --trust-policy=no-downgrade
// Al eliminar un paquete, todo el lockfile se vuelve a validar contra las políticas activas
pnpm remove left-pad --filter ./apps/web --trust-lockfile
// Instalación solo en los paquetes de workspace que cambiaron
pnpm install --filter "...[origin/main]"
// Añadir la ubicación del store a la clave de caché de CI
pnpm store path// Bun 1.4 — isolated installs + almacén virtual global + instalación offline
// bunfig.toml (raíz)
[install]
linker = "isolated"
globalStore = true
exact = false
// package.json
{
"name": "monorepo-root",
"private": true,
"workspaces": ["apps/*", "packages/*"],
"trustedDependencies": [
"esbuild",
"sharp",
"@prisma/client"
]
}
// Paso de instalación en CI (GitHub Actions) — bloqueado y compatible con offline
- name: Install dependencies
run: bun install --frozen-lockfile --prefer-offline
// Ver los scripts postinstall bloqueados
bun pm untrusted
// Marcar un paquete como confiable
bun pm trust sharp
// Instalación en paquetes de workspace específicos
bun install --filter "./apps/web"
// Instalación completamente offline (nunca sale a la red)
bun install --offlineNo hay un ganador absoluto; las dos herramientas optimizan para prioridades distintas. Si quieres mantenerte independiente del runtime y auditar la política en cada comando que modifica el lockfile, elige pnpm. Si ya usas Bun como runtime y la ganancia de disco/velocidad del almacén virtual global es crítica, bun install resulta atractivo. Ambas bloquean postinstall por defecto; la diferencia está en dónde colocan los puntos de auditoría. No mezcles las dos en el mismo repositorio — un solo lockfile, una sola fuente de verdad.
Solicita una consultoría gratuitaDepende del escenario. La medición que publica Bun compara sus propios linkers: en un fixture de React/webpack/Babel/jest de 1.400 paquetes, la instalación en caliente tarda 823,9 ms con el linker hoisted y 124,8 ms con el linker isolated + almacén global (Apple Silicon macOS, hyperfine). El content-addressable store de pnpm también se apoya en lecturas de disco en instalaciones en caliente, así que ambas son rápidas en las condiciones correctas. Debes medir la diferencia entre ambas herramientas en el tamaño de tu propio repositorio y tu estrategia de caché de CI — no traslades el resultado de un solo fixture a tu monorepo.