Yarn: De Diseño a Implementación

Primero, mi nombre es Maren Lison, soy una ingeniera de experiencia de desarrollo en Datadog. Y he estado liderando el desarrollo de YARN desde 2017, desde el punto cero hasta la versión 4.0 actual.

Dividí el contenido de esta presentación en tres partes. Primero vamos a hablar un poco sobre el YARN clásico. Luego pasaremos al YARN moderno, desde la versión 2.0 hasta hoy. Y finalmente, nos adentraremos en detalles interesantes sobre la implementación de YARN o algunos conocimientos meta sobre YARN.

Lo primero, el YARN clásico. Clásico es todo lo anterior a la versión 2.0. ¿Por qué creamos el YARN clásico? La respuesta está en el artículo del blog que se publicó en ese momento para presentar YARN, donde se encuentra esta interesante frase. A medida que el tamaño de nuestro código y el número de ingenieros crecía en Facebook, nos encontramos con problemas de consistencia, seguridad y rendimiento. En ese momento, el ecosistema de JavaScript era muy diferente de lo que es actualmente, y era muy difícil asegurarse de que cuando se ejecutaba un proyecto funcionara para todos en la organización. Eso es algo que realmente no funcionaba a la escala en la que operaba Facebook, por lo que decidieron destinar recursos para encontrar una solución.

Sin embargo, ahora planteemos la misma pregunta pero con un énfasis diferente. ¿Por qué creamos YARN? ¿Por qué no contribuimos simplemente a NPM? La razón es que en ese momento sentíamos que había tantas cosas diferentes que queríamos intentar abordar, que contribuir a NPM no tenía sentido. Cada proyecto tiene sus propias prioridades, y algunas de las cosas que YARN pretendía abordar no eran cosas que NPM pretendía desafiar, porque sentían que era la experiencia del desarrollador que querían tener. Eso es completamente válido. Decidimos que sería más fácil crear otro proyecto que hiciera diferentes compensaciones y siguiera un camino de exploración diferente. Contribuir no era realmente una opción porque no queríamos ir en contra de NPM en un proyecto que era completamente suyo. Recuerda que en ese momento NPM también era una empresa, por lo que tenían sus propias prioridades.

Cuando construimos YARN, decidimos centrarnos en cuatro áreas principales diferentes. La primera fue el determinismo. Es fácil recordar los archivos de registro como algo que se usa en todas partes, básicamente. Sin embargo, en ese momento eran muy raros. Éramos un proyecto. No estábamos imponiendo la versión de sus dependencias en diferentes instalaciones, lo que significa que todos obtendrían cosas diferentes. Sentimos que era importante que los proyectos que funcionan ahora funcionen en el futuro, y para eso, YARN tenía que hacer un trabajo enfocado en eso. Además, queríamos que YARN fuera seguro, es decir, queríamos detectar la mayor cantidad de errores posible antes de que se implementaran en producción. Por lo tanto, la estabilidad era muy importante para nosotros.

También era muy importante tener una UX limpia. Queríamos que YARN fuera una herramienta a la que cualquiera pudiera acceder sin tener un profundo conocimiento de cómo funcionan los gestores de paquetes y cómo se configuran los proyectos. Con ese fin, decidimos centrarnos un poco en la experiencia del usuario al trabajar con la CLI y no solo en la implementación del software en sí.

Finalmente, queríamos que fuera completamente de código abierto. Mencioné que NPM era una empresa, y en realidad todavía lo es, pero ahora es propiedad de GitHub. NPM era una startup, lo que significa que recibía inversiones de capitalistas de riesgo, y sentíamos que los incentivos no estaban completamente alineados con lo que necesitaba el ecosistema de JavaScript. Por eso queríamos que YARN fuera completamente de código abierto, y se lanzó como un proyecto que ni siquiera formaba parte de Facebook. Actualmente, Facebook no tiene ninguna participación en él. Solo es mantenido por personas de diferentes empresas.

La oferta inicial del producto cuando lanzamos YARN incluía cuatro cosas principales. La primera, por supuesto, eran los archivos de registro. Archivos de registro todo el día. En ese momento, NPM agregó shrinkwraps, que permitían registrar la versión de las dependencias, pero no estaban habilitados de forma predeterminada. También tenían un efecto en las instalaciones transitorias. Eran un poco extraños y queríamos tener algo más simple de entender y que estuviera habilitado de forma predeterminada. También incluimos un espejo sin conexión, que también seguía la misma estrategia de cómo asegurarnos de que el proyecto se siga instalando en el futuro. ¿Qué pasa si el registro de NPM se cae, ya sea temporal o permanentemente? ¿Podemos asegurarnos de que no nos afecte, porque no afecta nuestras instalaciones? El espejo sin conexión te permite almacenar los paquetes tarballs en la caché de tu proyecto, en algún lugar que tú controles, por ejemplo, dentro de tu repositorio Git, pero no necesariamente. También puedes almacenarlo en un sistema de archivos específico. De esta manera, incluso si el registro está caído, YARN aún puede instalar tu proyecto sin problemas. También incluimos emojis. Sé que cuando lees emojis como una característica del producto, no parece muy importante, pero en realidad lo era para nuestros usuarios. También creo que mostraba que la salida de la CLI es muy importante, y hacerla más fácil de analizar para los humanos tiene mucho sentido. Hoy en día lo hacemos con cosas diferentes a los emojis. Lo hacemos utilizando colores semánticos en los diferentes componentes que mostramos. Pero ese es el tipo de atención que decidimos poner en la experiencia del desarrollador.

Y finalmente, esto se trata más del mantenimiento de las propias características de YARN, pero entra en la categoría de estabilidad que mencioné anteriormente. YARN estaba completamente tipado usando Flow, no TypeScript en ese momento. Y eso era muy importante porque nos permitía detectar muchos problemas que de otra manera no habríamos descubierto si no hubiéramos verificado los tipos en el código base. NPM seguía una estrategia muy diferente en la que pretendían tener una cobertura completa a través de pruebas. Sin embargo, en nuestra experiencia, hacer algo así aún habría permitido que se pasaran cosas que no deberían haberse lanzado.

Entonces decidimos que valía la pena dedicar tiempo a escribir correctamente todo el código. A lo largo del año, también implementamos muchas características diferentes. Enumeré dos críticas para el futuro de YARN. La primera fue la implementación de espacios de trabajo. ¿Qué pasa si el proyecto es más que solo un paquete? Esto fue inspirado inicialmente por Lerna, que a su vez construyó esa característica para admitir el proyecto Babel. Pero eventualmente sentimos que era una idea muy interesante y debería ser admitida nativamente en el Administrador de Paquetes. Así que lo implementamos en YARN y los monorepos crecieron y crecieron, y ahora se utilizan mucho más que solo Babel.

Plug and Play también pretendía responder a la pregunta, ¿y si no necesitáramos instalar nuestros proyectos en primer lugar? Cada vez que haces un clon de git, luego ejecutas YARN install y luego esperas hasta que se instalen todas las dependencias. ¿Y si no tuviéramos que hacer eso? ¿Y si no tuviéramos modelos conocidos en cada carpeta diferente? ¿Y si pudiéramos reutilizar todos los paquetes de un proyecto con otro? Plug and Play respondió a todo eso. Sin embargo, con el tiempo, comenzamos a tener un pequeño problema. Por muy bueno que fuera, el YARN Classic realmente no había sido diseñado para admitir tales evoluciones drásticas. Los espacios de trabajo se habían construido como una ocurrencia tardía. Se construyeron sobre la lógica regular, por lo que tuvimos que hacer un par de actos para que funcionara. Y con el tiempo, eso significó que agregar características se volvió cada vez más difícil.

Cada vez que agregábamos algo, también corríamos el riesgo de romper algo más en otro lugar, y en lugares que a veces podían ser muy difíciles de entender. Así que queríamos poder avanzar rápido y no romper nada al construir YARN. Desafortunadamente, nuestro código base no lo admitía. Lo que nos llevó a YARN Modern y la necesidad de reescribir YARN, de reestructurarlo, de tomar todo lo que habíamos aprendido de YARN 1.0 y ponerlo en algo que creíamos que podría apoyarnos durante los próximos 10 años. Recuerdas las áreas de enfoque que mencioné antes, Determinismo, Estabilidad, UX Limpia y Código Abierto. También agregamos otras cuatro. La primera fue Monorepos. Decidimos desde el principio que todo sería un monorepo. Incluso si tienes un solo paquete en tu proyecto, eso es un monorepo con un solo paquete. Así que el concepto de monorepo se convirtió en el núcleo de YARN. Todo es un monorepo. No hay casos especiales de, oh, pero espera, aquí soy un espacio de trabajo, así que en realidad hay múltiples proyectos en todas partes. No. Todo es un monorepo. También optamos por el uso interno. Deberíamos usar las características que construimos.

Un problema que tuvimos con la implementación de los espacios de trabajo en YARN fue que en realidad no lo estábamos utilizando nosotros mismos cuando trabajábamos en YARN. Solo teníamos un único espacio de trabajo que se utilizaba solo para un paquete que rara vez publicábamos. Por lo tanto, nos resultaba difícil tener una buena idea de lo fácil o difícil que era trabajar en los espacios de trabajo. Cuando desarrollamos YARN 2, decidimos cambiar eso por completo. Decidimos que queríamos realmente esforzarnos en dividir nuestro código base en múltiples fragmentos para enfrentarnos directamente a un problema con el que ustedes, como usuarios, se enfrentan al trabajar en monorepos y espacios de trabajo de YARN.

Además, esto también nos llevó a otra preocupación que era la partición. En YARN 1.x, teníamos un par de archivos muy importantes que contenían mucha lógica. Y el problema era que si trabajábamos en esos archivos, sería muy fácil romper algo en otro lugar. Decidimos cambiar eso dividiendo mejor las diferentes partes de la aplicación de YARN para que si estamos trabajando en algo, no corramos el riesgo de romper accidentalmente algo en una parte no relacionada del software. También se relacionaba con los espacios de trabajo porque hicimos esta partición dividiendo la lógica en diferentes piezas.

Y finalmente, también queríamos que YARN fuera evolutivo. Mencioné que habíamos planeado el diseño de YARN 2 y más como si estuviéramos diseñando para los próximos 10 años. Eso es exactamente lo que queríamos. No queríamos tener que reescribir el software desde cero otra vez. Así que, esta vez, realmente hicimos un esfuerzo consciente de tomar todo lo que habíamos aprendido y mejorarlo de una manera que fuera estable. En cuanto al diseño de instalación, nos mantuvimos en lo que estábamos haciendo en YARN 1.x. Así que teníamos tres pasos diferentes. El primero es la resolución, donde tomamos todos los rangos de dependencia y los convertimos en versiones que representan un único paquete, un único archivo tarball. Luego descargamos todo de una vez, y una vez que todo ha sido descargado, comenzamos el enlace, que es cuando colocamos los paquetes directamente en el disco después de haberlos descargado. Sin embargo, lo que hicimos de manera diferente es que ahora tenemos un pipeline modular.

Durante la resolución, tienes diferentes resolutores que pueden encargarse de diferentes sintaxis de dependencias. Por ejemplo, tienes el resolutor npm, por supuesto, que maneja todo con la rama semver, pero también tienes el resolutor git, que puede convertir una etiqueta de rama git en un hash de git, o el resolutor de parches, que puede aplicar un archivo de parche a un paquete. Y todo eso se pasa a los fetchers, que implementan su propia lógica para obtener el contenido del paquete. Los resolutores son para metadatos, mientras que los fetchers son para archivos tarball. Y finalmente, durante el enlace, tenemos los linkers, que son muy importantes porque son los que permiten que YARN admita instalaciones no-modules, instalaciones pnpm con enlaces simbólicos y instalaciones pnp sin enlaces simbólicos ni no-modules. Gracias a los linkers, tienes muchas opciones sobre cómo quieres usar YARN. ¿Quieres usar YARN pnp y ser más consciente de las dependencias que estás utilizando? Está bien. Si no quieres preocuparte por nada y simplemente tener un gestor de paquetes que funcione como en YARN 1, solo usa un linker no-modules y funcionará perfectamente. El linker no-modules es en realidad más estable en YARN 4 de lo que solía ser en YARN 1. Hemos solucionado un par de errores más complicados. Así que si todavía estás en YARN 1, considera migrar a YARN 4 con un linker no-modules.

También dividimos los comandos en diferentes paquetes que llamamos plugins, pero eso no cambia nada para los usuarios finales porque esos plugins están incorporados por defecto en el archivo YARN.js que distribuimos a nuestros usuarios. Por ejemplo, todos los comandos yarn install, yarn add, yarn remove, yarn up están incluidos en el plugin essentials que contiene todos los comandos críticos para la experiencia delYARN usuario. Y todos los comandos relacionados con el registro de YARN se incluyen en un plugin diferente que es el plugin npm-cli. Así que tienes yarn npm-login, yarn npm-info, yarn npm-publish, todos estos comandos en el mismo lugar.

A lo largo del tiempo, decidimos hacer muchos puntos de división diferentes. Por ejemplo, tienes el plugin compat, que contiene un conjunto de reglas de compatibilidad que ayudan tanto a YARN como a pnpm a instalar correctamente proyectos que no están listando correctamente sus dependencias. Tienes el plugin constraints que implementa la regla de restricciones en Djane de la que voy a hablar un poco más tarde. Tienes el plugin exec que implementa el protocolo exec. Tenemos muchos paquetes diferentes y una pregunta que puedes tener es, ¿no es quizás un poco demasiado? La respuesta es no.

Verás, YARN siempre se distribuye como un solo archivo JavaScript, como mencioné, yarn.js, que contiene todos esos plugins preinstalados. Nuestros usuarios no necesitan ver ni preocuparse por los plugins que proporcionamos. Sin embargo, proporciona mucho valor a los colaboradores. Si eres alguien que quiere implementar una característica o solucionar un error, solo tienes que ir a nuestro repositorio y verás todos los títulos de las diferentes descripciones de los plugins. Te permitirá descubrir rápidamente qué es lo que necesitas cambiar para implementar tu característica o solucionar el error que viste. Y dividir la base de código no es un acto de distribución, no se trata de dividirlo en múltiples segmentos. Sin embargo, se trata de asegurarnos de que estamos delimitando todas las diferentes piezas deYARN para que sea más fácil de descubrir. Ahora, vamos a hablar un poco sobre detalles interesantes sobre cómo se implementaYARN, cosas que es posible que no sepas sobre nosotros. YARN se envía con un linter de proyectos, lo llamamos el motor de restricciones. Puedes llamarlo con YARN constraints y te permite crear reglas personalizadas que se aplicarán a tu proyecto.

Por ejemplo, en el propio repositorio de YARN, estamos creando una regla que obliga a que dos espacios de trabajo en el mismo proyecto no puedan tener la dependencia del mismo paquete, pero con diferentes versiones. Eso es algo que muchos proyectos desean, pero cada vez hay pequeñas sutilezas en la implementación real, por ejemplo, en Datadog, usamos una regla similar. Sin embargo, queremos algunos casos especiales que pueden tener diferentes versiones. Entonces, para hacer eso, solo tenemos que escribir una restricción y declarar el caso especial directamente dentro del código JS. Solía ser Prolog, así que solía ser constraints.pro. Sin embargo, la sintaxis era un poco extraña para nuestros usuarios, y eso es completamente comprensible. Prolog es un lenguaje muy interesante. Sin embargo, su sintaxis es un poco complicada. Así que, en YARN 4.0, introdujimos un nuevo motor basado en JS, que es más rápido y utiliza la sintaxis regular de JavaScript o TypeScript a la que estás acostumbrado. Así que ahora es mucho más fácil escribir JavaScript, escribir restricciones para YARN 4.0. Recientemente rediseñamos por completo el sitio web.

Si visitas yarnplicator.com, verás que es realmente hermoso. Francamente, estoy muy feliz con cómo se ve ahora. Para lograrlo, contratamos a un diseñador. Trabajamos con un diseñador ucraniano para el sitio web durante un par de meses. Y como puedes ver, el resultado es realmente genial.

También reescribimos la mayoría de la documentación para asegurarnos de que la mayoría de las páginas fueran más claras y directas. Sin embargo, a veces nos resulta un poco difícil ponernos en el lugar de alguien que recién está comenzando con YARN, por supuesto, porque somos los mantenedores, así que tenemos muchos contactos. Entonces, si ves algo que no está lo suficientemente claro, no dudes en contactarnos en Discord para hacérnoslo saber. Y, por supuesto, si quieres abrir un PR para proponer algo mejor, eso es aún mejor. YARN implementa una biblioteca de sistema de archivos. Un problema que teníamos con YARN 1 y que ya no tenemos con YARN 4 es que teníamos muchos problemas de compatibilidad con personas que usaban Windows debido a las rutas, especialmente las barras diagonales frente a las barras invertidas. Y para resolverlos en YARN 1.0, teníamos mucho código en varios lugares del software, haciendo que, si estábamos en Windows, hiciera la división usando una barra invertida en lugar de una barra diagonal. Y si olvidábamos hacer eso, significaba que teníamos un error que se enviaba silenciosamente a producción.

Entonces, en YARN 2 y 4, implementamos un paquete llamado yarn-pkg-slash-fslim que te permite tratar todas las rutas como si fueran POSIX. Todo se usa con barras diagonales regulares y están correctamente tipadas en TypeScript. Al hacer eso, nos aseguramos de que todo lo que ingresa al módulo fs de Node esté en la sintaxis correcta que esperamos, es decir, con una barra diagonal. Luego, la biblioteca las convierte en barras diagonales o barras invertidas, según el sistema real. Todo está centralizado en esta biblioteca, por lo que no tiene que estar dentro del código empresarial de YARN. Además, esta biblioteca de sistema de archivos también admite capas virtuales de Node.js, que son bastante avanzadas y te permiten superponer un sistema de archivos virtual sobre lo que el módulo fsa normalmente vería. Por ejemplo, un lugar donde lo estamos usando es cuando construimos la documentación de YARN. Creamos un sistema de archivos virtual que contiene todos los archivos generados para todos los comandos CLI de YARN. Para cada uno de esos comandos, generamos un archivo en el momento que contiene la documentación para esos comandos CLI utilizando el código fuente como fuente. Es bastante poderoso, aunque es muy avanzado, por supuesto, por lo que no es algo que quieras usar en todas partes. Realizamos un seguimiento de nuestro rendimiento. Una cosa muy importante cuando trabajas en un proyecto del tamaño de YARN es darte cuenta de que no tienes tiempo para hacer todo tú mismo. Es muy importante tener una buena automatización que te apoye para hacer el trabajo manual en lugar de hacerlo tú mismo. Uno de los lugares donde implementamos automatización es en el seguimiento del rendimiento de YARN en comparación con sí mismo y otros administradores de paquetes.

Entonces, cada par de horas, creo que es cada seis horas, algo así, estamos ejecutando un conjunto de pruebas tanto en la instalación de NestJS como en Gatsby y vemos cuánto tiempo tarda para todos los gestores de paquetes, dependiendo de múltiples parámetros. Por ejemplo, cuando hay un código completo instalado, cuando ya hay un archivo de registro, pero no hay caché, cuando hay caché pero no hay archivo de registro, cuando está todo a la vez. Y nos permite ver tendencias. Hoy en día, todos los gestores de paquetes son bastante iguales en velocidad, especialmente YARN 4 y PMPM son muy similares en tiempo de instalación. Sin embargo, es interesante para nosotros ver si enviamos algo que contiene una regresión de rendimiento o si alguno de los competidores logró encontrar una forma de aumentar significativamente su velocidad, en cuyo caso también investigamos para implementarlo. Eso es bastante interesante de hacer de forma automática.

Todavía en el ámbito de la automatización, también estamos realizando un seguimiento de la compatibilidad con muchos proyectos en el ecosistema de código abierto. Por ejemplo, cada cuatro horas, estamos ejecutando pruebas en ESBuild para asegurarnos de que podemos ejecutar YARN en ESBuild y que el proyecto que así instalamos se puede utilizar sin problemas. Por lo tanto, no solo ejecutamos pruebas de YARN, sino que también ejecutamos pruebas de ESBuild, Ocusaurus, ESLint cada hora. Cada vez que uno de esos builds se convierte en un RAIL, a veces sucede, por ejemplo, digamos que un proyecto comienza a depender de una dependencia que olvidaron declarar en su package.json, pone la prueba en rojo y comenzamos a trabajar con los mantenedores para hacerles saber sobre el posible problema que hay en su software. Descubrimos si es un problema con su paquete o con YARN. A veces sucede, aunque es raro, y trabajamos juntos para solucionarlo.

La caché de YARN contiene archivos ZIP y no TGZ. La razón de esto es que los archivos TGZ deben descomprimirse por completo para acceder a un solo archivo, mientras que los ZIP permiten acceder a un archivo dentro de todo el archivo sin tener que descomprimir todo. YARN te permite ejecutar directamente tus scripts mediante la inclusión dinámica de archivos desde la caché, y para hacer eso, necesitamos poder señalar el archivo al que accedemos dentro de la caché, por eso usamos ZIP y no TGZ. Consideramos usar un formato personalizado. Sin embargo, los archivos ZIP son compatibles de forma nativa con la mayoría de los sistemas operativos y herramientas de terceros, por lo que es bastante práctico poder usar ZIP directamente. También implementamos una extensión ZIPFS para VS Code para agregar soporte ZIP a VS Code.

Hay partes de YARN en pnpm. Si eres usuario de pnpm, te interesará saber que si estás usando la bandera node-linker en tu archivo npmrc sin el valor hoisted, le indicará a pnpm que instale el proyecto utilizando una carpeta regular no de módulos, lo cual puede ser útil para fines de compatibilidad, y eso está impulsado por el enlazador de YARN. Mencioné antes que tenemos un enlazador no de módulos, un enlazador de pnpm y un enlazador pnp. Tanto el enlazador pnp como el enlazador no de módulos son reutilizados por pnpm para que sus usuarios también se beneficien de ese tipo de instalaciones. Si estás utilizando esas configuraciones, estás utilizando YARN. También tenemos un intérprete de shell que es utilizado por pnpm. Si tienes la configuración del emulador de shell en verdadero, pnpm lo interpretará como que deseas ejecutar todos los scripts en tu packet.json a través de un intérprete especial que funciona tanto en Linux como en Windows sin tener que configurar shells especiales en tu sistema. Eso es algo que está implementado por YARN en JavaScript. Implementamos este shell portátil que funciona en todos los sistemas y lo publicamos como un paquete para que otros gestores de paquetes puedan reutilizarlo. YARN también contribuye a Node.js.

Por ejemplo, la iniciativa Core Pack, que tiene como objetivo utilizar fácilmente tu gestor de paquetes preferido independientemente del proyecto en el que estés trabajando, es algo que comenzamos nosotros mismos. Estamos trabajando con Node.js para hacerlo estable y habilitarlo de forma predeterminada. Estamos trabajando en grupos de trabajo donde intentamos abordar problemas importantes que también afectan a otros proyectos. Por ejemplo, el grupo de trabajo de cargadores, que tiene como objetivo definir qué es un cargador en el contexto de Node.js. Es posible que estés familiarizado con el concepto de cargadores, por ejemplo, para Webpack. ¿Qué significa eso para Node.js? Eso es algo en lo que estamos trabajando, junto con un par de personas más en el proyecto de Node.js.

Gracias por tu tiempo. Esta charla fue corta, así que estoy seguro de que tienes muchas preguntas. No dudes en hacerlas en Discord, y también puedes encontrarme en Twitter y GitHub usando el nombre de usuario Arcanist. Espero que hayas disfrutado esta charla. Que tengas un buen día.