pnpm vs npm vs yarn en 2026: lo corrí en mi monorepo real y el resultado me obligó a cambiar de criterio

La respuesta correcta para acelerar installs en un monorepo es hacer el hoisting más estricto. Sé que suena raro. Más strictness debería significar más errores de compatibilidad, más tiempo debugueando, más fricción. Y sin embargo, eso fue exactamente lo que me obligó a adoptar pnpm — después de que primero me rompió una dependencia de Radix UI en el peor momento posible.

Ese es el trade-off honesto que ningún benchmark sintético te muestra: pnpm es más rápido y más chico, pero su modelo de hoisting estricto tiene dientes. Cuando muerde, duele. Y la guía de migración oficial no te avisa cuándo va a morder.

Hace unos meses estaba en medio de un sprint, monorepo Next.js 16 con TypeScript estricto, Shadcn/ui, Radix UI, todo corriendo en Railway. Cambié de npm a pnpm siguiendo los benchmarks de siempre — los que miden un react con tres dependencias en una máquina limpia. En producción, el resultado fue distinto.

Mi tesis es esta: pnpm gana la comparación general en 2026, pero el costo de compatibilidad es real y medible. Yarn Berry es el más difícil de justificar hoy. Y npm mejoró tanto en la v10 que ya no es la opción obvia para descartar.

pnpm vs npm 2026 en monorepo: los números que importan

Corrí los tres en el mismo proyecto — monorepo con dos apps Next.js 16 y un paquete compartido de utilidades TypeScript. Misma máquina, mismo lockfile limpio, misma conexión. Los números de CI los tomé de Railway con caché deshabilitado para medir el cold install real.

Install time (cold cache, CI Railway)

pnpm es ~53% más rápido que npm en cold install y usa menos de la mitad de disco. Yarn Berry con PnP es interesante en disco, pero el número de install time no justifica el costo de compatibilidad de PnP — que es aún más agresivo que el de pnpm.

Con caché de CI activo (el escenario de todos los días), la diferencia se comprime pero no desaparece:

# Warm cache — mismo proyecto, tres runs promediadas
# npm: ~18s | yarn berry: ~14s | pnpm: ~9s

El caso que cambió mi criterio: Radix UI y el hoisting estricto

Esto es lo que los benchmarks no miden. pnpm por defecto no hace flat hoisting como npm. Cada paquete solo puede importar lo que tiene declarado en su propio package.json. En teoría es correcto. En práctica, hay dependencias que confían en el hoisting fantasma de npm — acceden a paquetes que no declararon explícitamente.

Me pasó con una versión específica de @radix-ui/react-dialog que dependía internamente de @radix-ui/react-compose-refs sin declararlo correctamente en su propio package.json. npm lo resolvía silenciosamente por el flat hoisting. pnpm lo rompía con un error críptico:

# Error que aparecía en el build de Next.js 16
# Cannot find module '@radix-ui/react-compose-refs'
# Require stack:
#   - node_modules/.pnpm/@radix-ui+react-dialog@1.0.5/node_modules/@radix-ui/react-dialog/dist/index.js

# No es un error tuyo — es la dependencia que no declara su propio dep

El fix que funcionó mientras esperaba el parche upstream:

# .npmrc en la raíz del monorepo
# Habilita hoisting público para los paquetes de Radix que tienen este problema
public-hoist-pattern[]=@radix-ui/*
public-hoist-pattern[]=@floating-ui/*

Este ajuste en .npmrc le dice a pnpm que haga hoisting público para esos scopes específicos, replicando el comportamiento de npm solo donde duele. No es elegante. Es pragmático.

Configuración real del monorepo pnpm

Si vas a usar pnpm en un monorepo Next.js 16, esta es la configuración que sobrevivió a producción. No la del tutorial de 10 minutos — la que quedó después de dos semanas de debugueo:

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'
  # excluimos carpetas de e2e para que no pisen las deps del monorepo
  - '!**/e2e/**'

# .npmrc — raíz del monorepo
# Hoisting público para paquetes que usan el flat hoisting de npm como feature
public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*
public-hoist-pattern[]=@radix-ui/*
public-hoist-pattern[]=@floating-ui/*

# Modo estricto para todo lo demás — el default de pnpm
node-linker=node-modules

# Shamefully hoist: NUNCA activar esto en producción
# shamefully-hoist=true  ← esto es rendirse; es convertir pnpm en npm caro

El shamefully-hoist=true que ves en algunos tutoriales es el camino de la rendición total. Si lo activás, estás usando pnpm con el comportamiento de npm — pagás el costo de aprender pnpm sin llevarte ningún beneficio de strictness.

Workspace protocol y las dependencias internas

// packages/ui/package.json — paquete compartido
{
  "name": "@mi-monorepo/ui",
  "version": "0.0.1",
  "dependencies": {
    // workspace:* le dice a pnpm que resuelva desde el workspace local
    // nunca desde npm registry — esto es clave para development
    "@mi-monorepo/utils": "workspace:*"
  }
}

// apps/web/package.json
{
  "dependencies": {
    "@mi-monorepo/ui": "workspace:*",
    // versión exacta de Next.js 16 — sin rangos en producción
    "next": "16.0.2"
  }
}

Los gotchas que ningún benchmark sintético mide

1. Scripts de lifecycle y el PATH de pnpm

pnpm no agrega los binarios de las dependencias al PATH del mismo modo que npm. Si tenés scripts que llaman a next o tsc directamente en el shell (no via package.json scripts), van a fallar:

# Esto falla con pnpm si next no está en tu PATH global
$ next build

# Esto funciona siempre — pnpm resuelve el binario del workspace
$ pnpm next build
# o via script en package.json:
# "build": "next build"

2. pnpm dlx vs npx — no son lo mismo

# npx instala y cachea globalmente por defecto
npx create-next-app@latest mi-app

# pnpm dlx instala en un directorio temporal, no cachea
# más limpio, más lento en repetición
pnpm dlx create-next-app@latest mi-app

# Para herramientas que usás seguido, instalá global:
pnpm add -g @railway/cli

3. TypeScript strict y los re-exports implícitos

Con TypeScript estricto y pnpm, los re-exports implícitos de paquetes mal tipados se rompen antes — lo cual en realidad es una ventaja disfrazada de problema. pnpm te obliga a descubrir dependencias implícitas que npm nunca te hubiera mostrado. Eso me pasó con una librería de utilidades que re-exportaba tipos de lodash sin tenerlo en sus propias dependencias.

Esto conecta con algo que ya mencioné en el post sobre supply chain en npm vs PyPI: el grafo implícito de dependencias es exactamente donde viven los vectores de ataque más interesantes. pnpm hace ese grafo explícito. Eso es incómodo al principio y valioso después.

4. Railway CI y la caché de pnpm

Railway no cachea node_modules por defecto. Con npm eso duele un poco. Con pnpm duele menos porque el store de pnpm es separado del proyecto:

# En tu Dockerfile o config de Railway
# Cachear el store de pnpm, no node_modules
ENV PNPM_HOME="/root/.local/share/pnpm"
ENV PATH="$PNPM_HOME:$PATH"

# El store vive fuera del proyecto — cacheable entre builds
RUN pnpm config set store-dir /root/.pnpm-store

Si no configurás esto, cada build en Railway hace un cold install aunque el lockfile no cambió. El store separado de pnpm es la feature que más impacta en CI — más que el install time en sí.

5. Yarn Berry en 2026: ¿para quién?

Siendo honesto: no encontré un caso de uso en mi stack donde Yarn Berry fuera la respuesta correcta. PnP rompe más cosas que el hoisting estricto de pnpm, la documentación asume que sabés exactamente qué estás haciendo, y la ventaja en install time frente a pnpm no es suficiente para justificar la fricción.

Yarn Berry tiene sentido si venís de un monorepo gigante ya configurado con PnP y no querés migrar. Si arrancás de cero hoy, pnpm es la respuesta más directa. Esto no es tribalism — es que no encontré un benchmark propio donde Yarn Berry ganara en algo que me importara.

Tabla de compatibilidad con el stack real

⚠️ = funciona pero requiere configuración adicional no documentada en el README oficial

FAQ: pnpm vs npm 2026 monorepo

¿Vale la pena migrar de npm a pnpm en un proyecto existente?

Si el proyecto ya está en producción y estable, evalualo por el costo de CI. Si tu pipeline de Railway o cualquier otro CI corre installs frecuentes, la diferencia de ~50% en cold install se acumula en horas de build por mes. Si el pipeline es corto o ya tiene caché agresivo, la urgencia baja. La migración en sí toma medio día más dos días de debugueo de edge cases — como el de Radix UI que conté arriba.

¿Qué es el hoisting estricto de pnpm y por qué importa?

En npm, todos los paquetes se instalan en un node_modules plano. Cualquier paquete puede acceder a cualquier otro paquete, aunque no lo declare como dependencia. pnpm en cambio crea un node_modules con symlinks donde cada paquete solo ve lo que declaró. Esto evita dependencias fantasma pero rompe paquetes que confían en el comportamiento plano de npm. La documentación oficial de pnpm explica el modelo en detalle.

¿shamefully-hoist=true resuelve los problemas de compatibilidad?

Técnicamente sí, pero es una rendición parcial. Si activás shamefully-hoist=true, pnpm se comporta como npm en términos de hoisting — perdés exactamente el beneficio de strictness que hace a pnpm valioso. La alternativa correcta es public-hoist-pattern para los scopes específicos que tienen el problema, no habilitar hoisting global.

¿Yarn Berry con PnP es mejor que pnpm en monorepos grandes?

En mis benchmarks, no. Yarn Berry PnP tiene una ventaja de disco interesante pero el costo de compatibilidad es más alto que el de pnpm. Además, el tooling de TypeScript y los IDEs tienen soporte más estable para el modelo de pnpm que para PnP. Para monorepos nuevos en 2026, pnpm es la apuesta más pragmática.

¿npm 10 mejoró tanto que ya no vale la pena cambiar?

npm 10 mejoró bastante — workspaces funcionan bien, el install es más rápido que npm 8. Pero en disco y en CI frío, la diferencia con pnpm sigue siendo sustancial (610 MB vs 1.4 GB en mi caso). Si ya tenés todo configurado con npm y no tenés un problema concreto de disco o tiempo de build, la migración puede no valer el costo. Si arrancás un proyecto nuevo, arrancalo con pnpm.

¿Cómo manejo las actualizaciones de dependencias en pnpm con monorepo?

pnpm update --recursive --latest actualiza todas las apps y paquetes del workspace de una vez. Lo que aprendí a hacer es correr esto en una rama separada, correr el build completo y revisar los cambios de lockfile antes de mergear. Con TypeScript estricto, los cambios de tipos rotos aparecen en el build — lo cual es exactamente la red de seguridad que describí en el post sobre functional programming en TypeScript.

Mi postura final (y lo que no compro de los benchmarks virales)

pnpm gana en 2026. Eso no está en discusión después de ver los números en producción real. Pero la narrativa de "simplemente migrá y listo" que circula en los posts virales de HN me parece deshonesta — o escrita por alguien que nunca corrió pnpm contra Shadcn/ui con una versión de Radix UI desactualizada.

El costo real de adoptar pnpm no es el install time ni el aprendizaje de la CLI. Es el día que algo se rompe en producción porque una dependencia transitiva confiaba en el hoisting plano y nadie lo documentó. Ese día existe. Me pasó. Se resuelve — pero hay que saber que va a pasar.

Lo que no compro: que Yarn Berry sea relevante para proyectos nuevos en 2026 sin un caso de uso muy específico. Y no compro que shamefully-hoist=true sea una solución válida — es posponer el problema hasta que alguien del equipo no entienda por qué el monorepo se comporta diferente en local y en CI.

Si venís de mi mismo stack (Next.js 16, TypeScript estricto, Shadcn/ui, Railway), la migración vale. Solo hacela con los ojos abiertos: configurá public-hoist-pattern para los scopes de UI, cachéá el pnpm store en CI, y mantené TypeScript estricto como tu red de seguridad cuando el hoisting detecta dependencias implícitas. Eso es exactamente lo que haría diferente si empezara de cero.

Mientras tanto, si estás viendo errores raros de módulos no encontrados después de una migración a pnpm, antes de entrar en pánico mirá si el paquete tiene sus propias dependencias bien declaradas. Con probabilidad alta, el problema es upstream — no vos.

Fuente original:

• pnpm official documentation — motivación y modelo de hoisting: https://pnpm.io/motivation

Este artículo fue publicado originalmente en juanchi.dev