Yarn en Profundidad: Por qué y Cómo

Hola a todos, para aquellos que no me conocen, mi nombre es Mael. Actualmente trabajo en Datadog y he estado liderando el desarrollo de Yarn durante algunos años. Hoy vamos a hablar extensamente sobre qué es y qué puede ofrecerte. Si bien no podremos abordar cada pequeña mejora de calidad de vida que ofrece, espero que al final de esta charla tengas una mejor idea de lo que hace que este proyecto sea único en nuestro ecosistema.

Primero, debemos discutir qué es realmente Yarn. Si le preguntas a alguien, probablemente te dirán que Yarn es un gestor de paquetes para JavaScript, y estarían en su mayoría en lo correcto. Pero eso es solo parte de la historia. Yarn no es solo un gestor de paquetes, tiene la intención de ser un gestor de proyectos. Un sistema de ejecución. De hecho, si lo piensas, Yarn te permite administrar scripts. Te permite dividir tu aplicación en modelos independientes. Pero como veremos más adelante, también se puede utilizar para gestionar los ciclos de lanzamiento, monitorear cómo tu equipo utiliza tus scripts, e incluso hacer cumplir estándares en tu monolito. Todas estas tareas van mucho más allá del típico gestor de paquetes, y cada lanzamiento empuja los límites aún más al introducir nuevas características.

Entonces, gestor de proyectos, suena bien. ¿Cómo llegamos allí? ¿Qué es lo que buscamos al gestionar PR? Vamos a discutir los valores fundamentales. Lo primero que debemos tener en cuenta es que somos una comunidad de colaboradores. El código abierto es un entorno muy exigente y la mayoría de los proyectos tienen dificultades para encontrar formas de hacer que su trabajo sea sostenible, y Yarn no es una excepción. Para ayudar con eso, confiamos mucho en nuestros colaboradores para ser el cambio que desean ver y contribuir de vuelta al proyecto que les gusta. De esta manera, realmente no vemos Yarn como un producto. Realmente lo vemos como un proyecto. En la práctica, esto significa que nuestro equipo central dedica tanto tiempo a trabajar en nuestra infraestructura como en el propio producto. Recientemente, pasamos de Webpack a ESbuild para facilitar la construcción de Yarn. Varios comentarios te permiten construir parte de los binarios de Yarn desde el origen, para que puedas probar fácilmente características independientes. Yarn se trata realmente de hacer posible que experimentes mucho más allá de lo que nosotros como equipo podríamos ofrecer por nosotros mismos. Un segundo valor importante que siempre tenemos en cuenta al fusionar PR es la solidez. Yarn debe decirte si algo está mal en tu aplicación. No debe permitirte cometer errores. No debe dejarlos pasar desapercibidos. No debe hacer suposiciones descontroladas. Esto puede sonar rígido porque tienes más errores de los que solías tener, pero es realmente crítico, ya sea que seas autor de aplicaciones o bibliotecas, necesitas tener confianza en que algo que funciona ahora lo hará en el futuro.

también funcionan en producción o cuando son instalados por tus consumidores. Otro es buenas prácticas. El panorama de JavaScript es amplio, cambia rápidamente y cuenta con muchas personas con opiniones muy marcadas. Como gestor de paquetes, estamos en una posición única para ayudar a nuestros usuarios a comprender la herramienta que están utilizando y guiarlos en el difícil camino. No solo usar Yarn debería resolver una necesidad práctica, también debería contribuir a que aprendas y te conviertas en un mejor ingeniero en el camino en términos de JavaScript DevOps. Llegamos al último de este conjunto, los comportamientos predeterminados, que están directamente relacionados con la experiencia del desarrollador. La mayoría de nuestros usuarios solo usarán los comandos predeterminados de nuestra herramienta, lo cual es algo bueno porque la mayoría de ellos, no tienen que recordar una gran cantidad de banderas de línea de comandos solo por el hecho de ejecutar un comportamiento específico. Por ejemplo, el hecho de que puedas ejecutar cualquier script agregando el prefijo en tu CLI con solo Yarn, puede parecer una cosa muy simple, pero seguramente es una de las razones por las que algunas personas pueden encontrarlo atractivo. La experiencia del usuario es realmente importante y crucial para la experiencia del usuario de Yarn.

Ahora hemos visto un poco de lo que Yarn afirma ser. Ahora, vamos a hablar un poco sobre DevOps. ¿Qué hace Yarn realmente por ti, hablando prácticamente? Vamos a repasar dos historias interesantes de proyectos que lo adoptaron. Uno es un proyecto de código abierto y el otro es una aplicación interna que usamos en mi empresa. Sin sorpresas, el primero es Yarn en sí mismo. Antes de sumergirnos, déjame contarte una historia divertida. En Yarn 1, en realidad no usamos Workspaces para desarrollar Yarn. Fue un verdadero problema para nosotros porque no solo los problemas estaban ocultos para los propios mantenedores, sino que tampoco nos enfrentábamos directamente a los valores que algunas características podrían tener. Como resultado, no estábamos emergiendo cosas aunque tal vez deberíamos haberlo hecho simplemente porque no podíamos ver cuán impactantes serían en realidad. Cuando usas Workspaces, es muy evidente que, por ejemplo, necesitas poder ejecutar un script en todos tus Workspaces a la vez. Pero como no usábamos los Workspaces, realmente no parecía un gran problema para nosotros en ese momento. Hoy en día, tenemos una regla informal de que el equipo de Yarn debe usar todas las características incorporadas en el núcleo, y creo que eso ha tenido un impacto positivo en el trabajo que hemos realizado hasta ahora al obligarnos a usar todas las características que enviamos como parte de Yarn en sí mismo.

Entonces, ahora hablemos de los flujos de trabajo. El primero que vamos a discutir son los Ready Cycles. Nuestro proceso anterior en Yarn 1 era muy simple. Solo teníamos un archivo único en la raíz del repositorio, y se esperaba que cada PR que las personas hicieran agregara una línea a él. Funcionaba bien, pero después de cambiar a un monorepo, no se habría escalado muy bien ya que necesitábamos la capacidad de lanzar cada espacio de trabajo, cada paquete, por separado. Entonces, desarrollamos el Flujo de Trabajo de Lanzamiento, que no es muy diferente del paquete set chance que tal vez conozcas. La idea es que cada PR que fusionamos también debe incluir un pequeño archivo creado por Yarn mismo que enumera todos los workspaces que han sido modificados por el PR y si necesitan formar parte del próximo lanzamiento. Nuestro CI valida el contenido de estos archivos, y en el momento del lanzamiento, simplemente le indicamos a Yarn que agregue todos los archivos de versión en paquetes clásicos. Otro flujo de trabajo que estamos utilizando son las instalaciones cero. La idea es que decidimos mantener la caché del proyecto dentro del propio repositorio.

Para los paquetes que tenemos, solo necesitamos mantener un solo archivo para cada paquete. Como resultado, cualquier persona que siga el repositorio podrá comenzar a trabajar con Yarn de inmediato. Lo que es más importante, significa que nuestros colaboradores pueden cambiar de una rama a otra casi sin costo en términos de cambio de contexto, lo cual es extremadamente valioso para nosotros porque queremos que los colaboradores puedan enviar muchas solicitudes de extracción diferentes y sentirse seguros trabajando en diferentes partes del código. Por lo tanto, poder cambiar de uno a otro es realmente importante para el flujo de contribución. Aún siento la necesidad de mencionar una última cosa al respecto, que es que este es nuestro compromiso y no necesariamente el tuyo. Por lo tanto, no tienes que almacenar tus dependencias en tu repositorio si no quieres, simplemente sentimos que funcionó bien para nosotros. Sin duda lo recomendaría, pero no es algo que realmente se te imponga. Un problema cuando tienes muchos espacios de trabajo, y tenemos muchos, creo que tenemos alrededor de 44 en este momento, es que se vuelve difícil asegurarse de que todos los espacios de trabajo en tu proyecto estén alineados en su configuración. Por ejemplo, ¿cómo puedes asegurarte de que todos los espacios de trabajo tengan la misma versión exacta de todas tus dependencias? Es demasiado fácil tener un espacio de trabajo que se actualice de repente sin actualizar los demás, por lo que hemos lanzado una función llamada restricciones, que tal vez prefieras porque utiliza un lenguaje de programación bastante novedoso en su configuración, utiliza productos, y gracias a la función de restricción, podemos aplicar patrones específicos en todos los espacios de trabajo con muy pocas líneas. Y lo que es mejor, Yarn a menudo puede aplicar las correcciones por sí mismo. Por ejemplo, en el repositorio de Yarn, usamos esta función para garantizar la misma versión de las dependencias en todos los espacios de trabajo, pero también la usamos para asegurarnos de que todos nuestros paquetes en JSON enumeren los scripts de compilación correctos, para asegurarnos de que todos ellos tengan el campo de repositorio correcto, para asegurarnos de que ninguno de ellos esté marcado como privado, este tipo de cosas. Estos tres ejemplos te dan una buena idea del valor que los proyectos de código abierto pueden obtener de Yarn. En general, significa que ya no necesitan aprender o configurar conjuntos de herramientas, porque esos espacios de trabajo han recibido directamente soporte de primera mano. Dicho esto, incluso los proyectos internos pueden beneficiarse de Yarn. Y para hablar de esto, voy a hablar sobre Datalog. Trabajo en Datalog y Datalog es una gran aplicación web junto con una infraestructura de JavaScript considerable que admite todo, desde el linting hasta las implementaciones. Yarn ocupa un lugar realmente central en este mecanismo y voy a mencionar tres ejemplos. El primero es la integración de telemetría. Si no sabes qué es Datalog, estamos haciendo un monitoreo en la nube realmente bueno, extrayendo señales de métricas arbitrarias. Dado este ADN, supongo que no te sorprenderá saber que también monitoreamos la forma en que nuestros desarrolladores interactúan con nuestra infraestructura y, en particular, en términos de tiempo de respuesta. Para lograr esto, escribimos un complemento para Yarn que observa todos los scripts que se ejecutan, cuánto tiempo tardan y lo registra todo en el panel de control. Todos estos datos luego nos ayudan, al equipo de la plataforma front-end, a identificar posibles cuellos de botella antes de que se conviertan en un problema y, en general, a priorizar nuestro trabajo. Como vimos con el propio repositorio de Yarn, verificar las dependencias tiene efectos poderosos en la capacidad de una persona para continuar eficientemente con un proyecto. Pero incluso en entornos corporativos, este patrón tiene sus usos. Según nuestros datos, el registro remoto se cae aproximadamente una vez al mes. Y al mantener nuestra propia copia de los paquetes, nunca nos bloqueamos durante nuestras implementaciones. Además, a pesar de un volumen muy alto de comentarios en nuestro repositorio principal, nuestra CI no pierde mucho tiempo ejecutando instalaciones porque todos los paquetes ya están dentro del repositorio. Entonces, una vez que lo llamas, todo está ahí. Y dado que el clon generalmente se almacena en caché entre cada ejecución de CI, todo ya está instalado en la práctica. En resumen, en lugar de tener que pasar minutos instalando proyectos

en cada CI, ahora es solo cuestión de segundos. Y un último punto que quiero mencionar. Entonces, tenemos un proyecto grande y muchas dependencias. Algunas de ellas tienen errores y nosotros intentamos solucionarlos y enviar el parche al repositorio principal. Pero hasta que las correcciones se fusionen, necesitamos alguna forma sencilla de usarlas localmente y al mismo tiempo mantener cierto nivel de auditabilidad. Porque no queremos, por ejemplo, editar directamente los archivos dentro de la carpeta de nodos. Por lo tanto, existen algunas herramientas de terceros solo para eso. Por ejemplo, el proyecto de paquetes de parches. Pero no están soportados de forma nativa de manera integrada con el sistema de caché y todas sus funciones. Por lo tanto, eso es muy útil porque no tenemos que depender de herramientas de terceros que no estarían tan bien integradas. Entonces, los casos de uso que hemos revisado te dan una buena idea de lo que YARN tiene para ofrecer. Pero debes tener en cuenta que estos son solo ejemplos. Por ejemplo, no hemos hablado de cómo YARN puede mantener tus paquetes comprimidos en el disco y compartirlos entre proyectos si eso es lo que prefieres, o cómo puedes vender paquetes directamente desde repositorios de git, o cómo tus scripts se vuelven automáticamente portátiles tanto en Windows como en POSIX. Y eso en sí mismo es solo una lista rápida de un solo sitio. Realmente te sugiero que consultes la documentación para encontrar muchas otras características nuevas de las que quizás ni siquiera estés al tanto.

Hasta ahora hemos discutido qué es Yarn, qué puede ofrecerte a ti y a tu organización, pero ahora quiero aprovechar la oportunidad para ir más allá de lo habitual y contarte por qué funciona tan bien. Así que vamos a sumergirnos rápidamente en el desarrollo de Yarn en sí mismo.

Una gran parte de nuestro éxito radica en nuestra infraestructura. Puede sorprender que el activo más valioso que tenemos no sea Yarn en sí, sino las capas construidas a su alrededor. Pero ese es realmente el caso. Probablemente hayas notado que la velocidad de iteración de Yarn está muy por encima del estándar de la industria. Y una gran razón para eso es que hemos invertido muchos recursos en solidificar nuestras bases desde el principio. Un ejemplo de esto son las pruebas de extremo a extremo. Cada cuatro horas se ejecuta un conjunto de pruebas exhaustivas. Pero en lugar de probar el comportamiento de Yarn, en realidad probamos proyectos de terceros populares del ecosistema. Así que, por ejemplo, probamos Next.js, Create.react.app, Gatsby, Angular, Jest, y esos son solo algunos de los nombres importantes que monitoreamos. Si alguno de ellos envía accidentalmente algo incompatible con Yarn, o viceversa, si Yarn envía accidentalmente una regresión, lo sabemos en menos de cuatro horas y podemos trabajar de inmediato con los mantenedores para encontrar una solución. Aunque no sea común, tener este mecanismo en su lugar significa que podemos permitirnos ser un poco menos conservadores de lo habitual, porque sabemos que nuestras pruebas de extremo a extremo podrán detectar si algo se rompe en el ecosistema debido a nuestro trabajo. De manera similar, hicimos un gran esfuerzo para construir nuestra base de código utilizando las últimas herramientas disponibles, incluyendo TypeScript, y realmente no puedo enfatizar lo suficiente los beneficios que obtuvimos. No solo nos ayuda a evitar errores tontos en nuestras propias solicitudes de extracción como parte del equipo principal, sino que también aumenta la confianza que podemos tener de que una solicitud de extracción de alguien que contribuye a Yarn por primera vez no tendrá efectos imprevistos. Y finalmente, desde la perspectiva de alguien que contribuye a Yarn por primera vez, es muy útil tener directamente los tipos y disfrutar de todos los beneficios que un buen IDE con soporte de TypeScript puede brindarte directamente. Por último, nuestro último cambio importante también vino con una revisión completa de nuestra estrategia de pruebas. En ese momento teníamos un montón de pruebas unitarias en Yarn 1 y creamos varias clases del núcleo y activamos sus métodos para cambiar sus comportamientos. Funcionó lo suficientemente bien durante un tiempo, pero este enfoque de pruebas unitarias resultó difícil de mantener a largo plazo. Las refactorizaciones eran prácticamente imposibles porque habría sido necesario reescribir todas las pruebas, ya que cada prueba se basaba en la arquitectura. Así que para Yarn 2, decidimos probar algo diferente y nos inclinamos hacia las pruebas de integración. Así que volvimos a escribir todas las pruebas de forma incremental, pero esta vez las actualizamos para usar directamente el binario de la CLI, exactamente como lo harían los usuarios reales. Este cambio muy simple en el concepto nos permitió eliminar muchos costos de mantenimiento y facilitar mucho a los contribuyentes externos entender cómo escribir pruebas. Ahora todo lo que tienen que hacer es simplemente escribir comentarios en la CLI. Creo que la lección aquí es muy simple. Para escribir código de manera eficiente, debes confiar en tu infraestructura. Y para hacer eso, a veces debes aceptar pagar costos por adelantado para asegurarte de que podrás alcanzar una velocidad de iteración más rápida y disminuir el riesgo de agotamiento para tu equipo como una característica adicional, pero sin estar completamente convencido de que nada se romperá. Otra razón por la que Yarn es Yarn es la arquitectura. Más precisamente, una forma particular en la que es completamente modular a partir de Yarn. Como mencioné anteriormente

Yarn solía ser un monolito. Workspaces no existían al principio, por lo que no los usábamos. Yarn era solo una gran base de código y todo importaba clases de varios archivos, pero cuando trabajamos en Yarn, quedó claro que algunas partes de la aplicación se beneficiarían de ser independientes del resto, incluso si solo era para evitar que importaran accidentalmente componentes no relacionados de los que ni siquiera deberían ser conscientes en la práctica. Así que una de las primeras cosas en las que trabajé fue cómo hacer que Yarn fuera modular. Avancemos rápidamente hasta hoy, ahora tenemos un núcleo que contiene todos los algoritmos críticos y expone una serie de interfaces que los modelos pueden implementar como deseen. La mayoría de las características que ves en Yarn hoy en día se implementan de esta manera. La comunicación con el registro de npm, es un modelo. La generación de paquetes tarball es un modelo. Y el plug and play en sí mismo, es un modelo. Así que solo en el momento de la publicación todos esos modelos se agrupan para generar la CLI que conoces. Curiosamente, esta arquitectura también facilita mucho la extensión de Yarn con nuevas funcionalidades. Por ejemplo, el comando focus, tal como lo implementamos, son literalmente cien líneas dentro de su propio modelo. Si quisieras, podrías implementarlo tú mismo. Y eso es realmente importante porque si un comportamiento no cumple con tus expectativas, no tienes que conformarte con ello. Simplemente puedes implementar uno nuevo y hacernos saber cómo va. Para darte un ejemplo, en los últimos meses al menos dos miembros de la comunidad han comenzado a resolver sus implementaciones de monorepo ofreciendo complementos dedicados a su caso de uso. Y gracias a su experiencia, obtenemos una mejor comprensión de cómo deberían funcionar las implementaciones y eventualmente podremos construir un flujo de trabajo estándar basado en esas experiencias. Entonces, ¿dónde vemos a Yarn en el futuro? Nadie puede predecir realmente lo que va a suceder pero puedo decirte lo que está sucediendo actualmente. Estamos trabajando en la próxima versión principal de Yarn, que será Yarn 3. Tendrá una serie de mejoras, corregirá algunos comportamientos en nuestra CLI, agregará nuevas características, mejorará el rendimiento de los comandos comúnmente utilizados y hará que nuestro ecosistema de complementos sea aún más potente. Al mismo tiempo, estamos comenzando a explorar la posibilidad de hacer que Yarn sea sostenible mediante un programa de patrocinio. Mencioné anteriormente que los proyectos de código abierto requieren muchos esfuerzos, recursos y tiempo, y ahí es donde puedes ayudarnos. Si tú o tu equipo están interesados en patrocinar parte del tiempo que dedicamos, algunas de las versiones que lanzamos, contáctanos y estaremos encantados de discutir los términos que sean favorables para ambas partes. Todo esto para decir que Yarn está muy vivo y diría que está en mejor forma que nunca antes. Nuestro equipo está alineado, nuestros objetivos son claros y nuestra visión es sólida. Ciertamente hemos tomado un rumbo más orientado que antes y creemos que para la mayoría de las personas seguirá siendo un resultado positivo saber que la herramienta te protegerá de tus errores. Por supuesto, diferentes personas pueden preferir diferentes tipos de herramientas y eso está bien porque ningún proyecto tiene que complacer a todos. Bueno, hemos llegado al final de esta rápida presentación. Espero que la hayas disfrutado. Ahora estaré encantado de responder a las preguntas que tengas sobre este tema. Gracias. Hola Mel, realmente fue una gran charla, la disfrutamos mucho y creo que una de las primeras cosas que debemos hacer es ver los resultados de tu pregunta, que me pareció

realmente interesante. ¿Qué buscas en un gestor de paquetes en tu gestor de paquetes? preguntaste a la audiencia y para ser honesto, me sorprendió. No me sorprendió porque la simplicidad es importante, pero el 80 por ciento dijo obviamente simplicidad cuando estabas desarrollando yarn o mientras mantienes yarn, ¿esto es lo que son los valores fundamentales que intentas mantener y asegurarte de cumplir? Sí, como mencioné en la charla, una de las principales cosas que buscamos es tratar de proporcionar una buena experiencia para los desarrolladores así que no estoy completamente sorprendido al ver que la simplicidad gana con una ventaja considerable sobre los otros números porque sí, es algo en lo que realmente invertimos mucho tiempo para asegurarnos de que por ejemplo, ejecutar yarn con el comando se pueda hacer sin la palabra 'run' o este tipo de cosas primero, que funcione bien, así que sí, estoy feliz de ver que a la gente también le gusta. Sí, definitivamente resultados interesantes. Tenemos algunas preguntas de la audiencia, así que prepárate. AC pregunta uno de los grandes beneficios de pnpm es la cantidad de espacio que ahorra en tu estación de trabajo. ¿Yarn 2 aborda esto? Sí, una de las cosas interesantes con pnp es que podemos tener un almacenamiento global que contiene todos los paquetes y en lugar de copiar todos los archivos en cada carpeta, simplemente hacemos referencia directamente a este almacenamiento principal. Tenemos dos formas de hacer esto. La primera es seguir haciendo la copia, pero usando una copia en sistemas que lo admiten o enlaces externos. Y otra forma es simplemente generar el archivo que hace referencia al caché global, por lo que literalmente no tienes nada dentro de tu proyecto. Además, todos los paquetes que se instalan por tmp están comprimidos en formato zip, por lo que, por ejemplo, de la v1 a la v2, instalar create react app es al menos un tercio de lo que era antes. Interesante, eso también contribuye a la velocidad en el um, así que cnos. No estoy seguro de cómo pronunciar este nombre de usuario, pero cinos pregunta si al usar yarn versión 1, ¿es seguro ejecutar yarn install en un mono repositorio con módulos de nodo preexistentes? Seguro, sí, realmente debería serlo, hay algunos errores en la v1 que se han solucionado a lo largo de la versión, así que ahora estamos en la 2.4 y estamos a punto de comenzar a lanzar versiones candidatas para la 3.0, así que la 1.0 es algunas versiones antiguas, pero debería ser bastante seguro instalar un proyecto incluso si ya hay un módulo. Genial, y William pregunta, ya que yarn ahora es completamente TypeScript, ¿has considerado usar deno en lugar de node? No realmente. Actualmente estamos bastante satisfechos con node. Algo en lo que estamos trabajando actualmente es si podríamos ejecutar yarn dentro de un navegador, lo que reduciría las dependencias en el tiempo de ejecución de node. Ahora mismo tenemos demasiadas partes del núcleo que dependen de API como los flujos de node que no se pueden simular fácilmente para Deno. Interesante. ¿Tienes algún consejo para migrar de un sistema de múltiples repositorios basado ennpm a un mono repositorio con yarn, especialmente en lo que respecta a la configuración de CI para implementables múltiples? Estamos trabajando en sistemas de lanzamiento porque, cuando nos mudamos a la v2, una de las cosas que hicimos fue dividir el repositorio en múltiples espacios de trabajo independientes que se implementan cuando es necesario. Así que entre lanzar versiones y crear implementables es más o menos lo mismo. Así que estamos construyendo herramientas que nos permitan hacer este tipo de cosas más fácilmente. Ahora mismo, de hecho, estoy trabajando en la función para permitirnos hacer una versión preliminar de paquetes en solo una línea de comando.

Eso es un gran trabajo. Realmente tengo que felicitarte por ser el mantenedor de un proyecto de código abierto y tan ampliamente adoptado. Me gustaría hacer una pregunta propia y preguntar cómo es ser el mantenedor de código abierto de un proyecto tan ampliamente adoptado y con tantos usuarios, probablemente muchos problemas y solicitudes futuras, etc. Es muchas cosas diferentes. Por un lado, tienes mucha presión tanto de las personas que usan tu software como de aquellos que en realidad no lo usan pero les gustaría hacerlo. Por otro lado, necesitas encontrar un equilibrio entre las características que implementas y las que quieres mantener porque a veces la gente viene y nos pide características, pero sabemos que no las usaríamos así que tenemos que rechazarlas porque no serían adecuadas para el proyecto. Y además de eso, necesitamos brindar una buena experiencia a los colaboradores para que puedan hacer cambios y ayudar a mejorar el código poco a poco. Y creo que eso es algo de lo que estoy realmente feliz es que durante los últimos dos años hemos adquirido muchos colaboradores que realmente se quedan en nuestro Discord y siguen participando en la comunidad y es mucho menos solitario de lo que era al principio, donde principalmente eran uno o dos colaboradores y en su mayoría internos de una empresa. Wow, gran trabajo. Sé que a menudo se siente

ingrato. Así que siento la necesidad de decir gracias por tu excelente trabajo de código abierto. Algunas preguntas más llegan de la audiencia. Mucha participación en esta charla. Entonces Mac pregunta si Yarn ayuda con un enfoque de múltiples repositorios. No tanto. Nos estamos enfocando mucho en tener un mono-repo porque creemos que es la forma correcta de gestionar proyectos grandes en la actualidad. Dicho esto, no hay nada que impida tener Yarn instalado en múltiples repositorios y tratar cada uno de ellos como un proyecto independiente. Lo único es que si haces esto, no te beneficiarás de algunas de las herramientas que hemos construido. Por ejemplo, la que mencioné donde puedes gestionar fácilmente las versiones y actualizaciones entre múltiples espacios de trabajo. Así que si no quieres usar un mono-repo, está bien. Simplemente no tendrás esta característica y algunas otras. Algunas de las características

están dirigidos específicamente a monorepos. OurX, ¿utilizarías npm en lugar de Yarn en un escenario o caso de uso específico y, de ser así, cuál sería? Mi opinión es que la elección del administrador de paquetes no depende tanto de la apreciación del usuario como de los mantenedores. Por ejemplo, cuando hago una solicitud de extracción a proyectos que están configurados para utilizar npm, entonces uso npm. Si hago una solicitud de extracción a un proyecto que está configurado para utilizar Yarn, entonces uso Yarn. Así que a veces uso npm porque contribuyo a muchos proyectos y algunos de ellos utilizan npm. Entonces, sí. Utilizar el administrador de paquetes adecuado para el trabajo, ¿estás diciendo? Exactamente. Tmall, tenemos tiempo para un par de preguntas más. Las responderé y cualquier pregunta que no podamos responder en la transmisión en vivo, estaré disponible en el chat espacial y en Discord, así que siéntete libre de continuar la conversación. Así que dos preguntas más y luego pasaremos a la siguiente charla. Con nuevas herramientas que se están construyendo en otros lenguajes como Yes Build y Go, por ejemplo, parece que la comunidad busca valorar la velocidad en sus herramientas. ¿Crees que esto sería beneficioso o habría espacio para hacer esto con yarn? Una de las cosas en las que hemos trabajado es la instalación cero. La idea es que la instalación más rápida que puedes tener para tu proyecto es no tener instalación en absoluto. Estaba funcionando bien, solo necesitamos un poco más de apoyo de proyectos de terceros y de la comunidad para llegar al punto en el que sea completamente fácil de usar. Dicho esto, en cuanto a la pregunta de si aportaría valor a yarn, por ejemplo, estar escrito en un lenguaje nativo. No creo que sea así, porque es un poco diferente en nuestro caso en el sentido de que el valor principal que obtenemos al estar en TypeScript es la facilidad de contribuir a yarn. Una de las cosas muy importantes para nosotros es hacer que sea una buena experiencia para los desarrolladores trabajar con yarn, pero también contribuir a él, y si usáramos, por ejemplo, algo como C++ o Rust o Go o cualquier otra cosa, sería mucho más difícil encontrar colaboradores que puedan solucionar los problemas que tienen con yarn. Así que para nosotros, el obstáculo está más en términos de experiencia de contribución que en la velocidad en este momento. Por supuesto, también hay que pensar en el mantenimiento a largo plazo de un proyecto. Así que la última pregunta de Matt. Hemos tenido varios problemas al intentar migrar un gran monorepo de la versión uno de yarn a la versión dos. El mayor problema provino de PNP con nuestros propios paquetes y paquetes de terceros. ¿Algún consejo para hacer una transición sin problemas? El primer consejo, si tienes problemas con PNP, es que no estás obligado a usarlo. Existe el complemento non-models que funciona muy bien y recibe mucho apoyo de algunos de nuestros colaboradores principales. Así que si por errores no puedes usar PNP, está bien, simplemente usa non-models. Dicho esto, tenemos muchas formas de resolver problemas uno por uno si aún quieres solucionarlos con PNP. Por ejemplo, con la configuración de extensiones de paquetes puedes declarar las dependencias que faltan en tus paquetes. Y ese es quizás el problema principal que la gente tiene, que sucede si un paquete en algún lugar en mi árbol de dependencias no lista sus dependencias, ¿qué puedo hacer? Con esta configuración, simplemente puedes declararlas tú mismo en tu archivo .yarn-rc.yaml y funcionará. También tenemos yarn-pkg.doktor que es un paquete que publicamos que analiza tus fuentes para tratar de averiguar cuáles son los lugares donde podrías haber olvidado declarar una dependencia. Así te ayuda a hacer tus proyectos más estrictos y depender menos del hoisting. Y si realmente no estás seguro por dónde empezar, tenemos nuestro servidor de Discord y estaremos encantados de ayudar a cualquiera que venga con preguntas. Genial, muchas gracias, Mil, por tu excelente charla y tus respuestas muy útiles. Encuentra a Mil en su sala de conferencias y en el Chat Espacial y en Discord. Esperamos verte nuevamente en el futuro con nosotros, Mil. Gracias. Gracias.