yarn en breve: Berry, Plug'n'Play y por qué no se impuso

La historia de yarn es, en miniatura, la historia del progreso de todo este campo. Yarn Classic apareció en 2016 y avergonzó a npm hasta obligarle a adoptar lockfiles y velocidad. Yarn Berry, en 2020, fue mucho más lejos con Plug’n’Play: abolir node_modules por completo y sustituirlo por un mapa de resolución. Sus ideas más ambiciosas —los zero-installs, un mapa en vez de un árbol de carpetas— eran técnicamente brillantes y el ecosistema las rechazó en gran medida. Esta lección explica qué es PnP, qué prometen los zero-installs y por qué en 2026 el estándar del layout estricto acabó siendo pnpm.

Yarn Classic: el aguijón que despertó a npm

En 2016, con npm 3 aplanando árboles de forma no determinista y lento, Facebook publicó Yarn Classic, la línea 1.x. Traía tres cosas que hoy damos por sentadas: un yarn.lock que fijaba el árbol resuelto, descargas paralelizadas y una caché offline. Su mera existencia forzó a npm a reaccionar —package-lock.json llegó en npm 5, en 2017— y elevó el listón para todo el ecosistema.

Cumplido ese papel histórico, Yarn Classic quedó congelado en mantenimiento. Sus ideas se volvieron el mínimo común de todos los gestores, y el equipo redirigió su energía a una reescritura completa. La 1.x sigue funcionando, pero es legado que no conviene empezar a usar en 2026: cualquier proyecto nuevo que elija yarn debería ir a Berry.

Plug’n’Play: abolir node_modules

Yarn Berry —la 2.x en adelante— fue esa reescritura, con una tesis provocadora: si node_modules es la fuente de los males, elimínalo. Plug’n’Play (PnP) hace justo eso. En lugar de desplegar un árbol de carpetas, guarda los paquetes como archivos zip en .yarn/cache y genera un único archivo, .pnp.cjs, que es un mapa de resolución explícito: dado un paquete y una versión, dónde está su zip y qué otros paquetes tiene permitido resolver.

node_modules/  (miles de archivos, arbol en disco)
      |
      v
.pnp.cjs       (un mapa: paquete + version -> ruta en el zip + deps permitidas)
.yarn/cache/   (paquetes comprimidos en zip)

Node no sabe leer ese mapa por sí solo, así que Berry parchea el resolvedor mediante un loader que consulta .pnp.cjs en vez de recorrer carpetas. Las ventajas son reales y notables: instalaciones sin el coste de escribir un árbol enorme, arranque más rápido porque no hay que hacer stat de miles de archivos, y resolución exacta. Las fantasmas son imposibles, porque el mapa es el contrato y solo autoriza lo que se declaró.

El modo de enlazado se elige en .yarnrc.yml, y ahí asoma la tensión que atravesó todo el proyecto: yarn terminó ofreciendo varias estrategias, incluida la de recrear el mismo node_modules que PnP nació para abolir.

nodeLinker: pnp              # el modo estricto original de Berry
# nodeLinker: pnpm           # arbol de symlinks al estilo pnpm
# nodeLinker: node-modules   # la via de escape totalmente compatible

Zero-installs: clonar y ejecutar

Sobre PnP, Berry ofrece su idea más vistosa: los zero-installs. Como los paquetes son zips en .yarn/cache y toda la resolución cabe en .pnp.cjs, puedes versionar ambos en git. Quien clona el repositorio obtiene un proyecto listo para ejecutar sin paso de instalación: git clone y a correr, sin negociar con el registro ni desplegar node_modules.

Para arranques en frío de CI y para reproducibilidad total es genuinamente potente: el estado instalado es el estado versionado, sin ventana entre clonar y poder ejecutar. Pero tiene un coste que a muchos equipos les resultó inasumible.

flowchart LR
imp[import express] --> q{como resuelve}
q -->|node_modules| walk[camina carpetas hacia arriba]
q -->|PnP| map[consulta el mapa pnp cjs]
walk --> disk[lee del arbol en disco]
map --> zip[abre el zip en yarn cache]
style q fill:#f9e2af,color:#11111b
style map fill:#89b4fa,color:#11111b

Por qué no se impuso y el estado en 2026

El talón de Aquiles de PnP es la última fila de la tabla. Durante quince años, medio ecosistema asumió que node_modules existe como carpetas reales en disco: bundlers que leen archivos directamente, frameworks, editores, herramientas de compilación nativa, scripts que hacen stat de rutas. PnP rompe esa suposición universal.

Aunque Berry publicó un protocolo de parches y loaders conscientes de PnP, la fricción era constante: cada herramienta que no entendía el mapa había que adaptarla o remendarla. El propio yarn terminó añadiendo el linker de node-modules como vía de escape —una admisión implícita de que la compatibilidad pesaba más que la pureza—, y el coste de versionar zips incomodaba a equipos con repos ya grandes.

En 2026 el panorama está asentado. Yarn Berry, en su línea v4, sigue vivo y mantenido, con un ecosistema de plugins, un sistema de constraints para gobernar dependencias en monorepos, y uso a escala en algunas organizaciones —notablemente en el linaje de donde salió—. PnP conserva una minoría devota que valora sus garantías. Pero la corriente principal que quería estrictitud sin impuesto de compatibilidad eligió pnpm, que resuelve los mismos problemas —dedup y fantasmas— conservando un node_modules real que todas las herramientas ya sabían leer. Yarn Classic, por su parte, es fin de línea.