Yarn en Profundidad: Por qué y Cómo

Hola a todos, para aquellos que no me conocen, mi nombre es Maer. Actualmente trabajo en Datadog, una empresa centrada en la monitorización en la nube, y he estado liderando el desarrollo de Yarn durante algunos años. Hoy vamos a hablar extensamente sobre qué es Yarn y qué puede ofrecerte. Espero que al final de esta charla tengas una mejor idea de lo que hace que este proyecto sea único en nuestro ecosistema. Entonces, si le preguntas a alguien, probablemente te dirán que Yarn es un gestor de paquetes para JavaScript y estarían en lo correcto. Pero eso es solo parte de la historia. Yarn no es solo un gestor de paquetes, está diseñado para ser un gestor de proyectos. Y de hecho, si lo piensas, Yarn te permite administrar scripts. Te permite dividir tu aplicación en modelos independientes. Como veremos más adelante, también gestionará tus ciclos de lanzamiento, monitoreará el uso de scripts e incluso aplicará estándares de monorepo. Todas estas tareas van mucho más allá del típico gestor de paquetes y cada versión que lanzamos empuja aún más los límites. Entonces, es un gestor de proyectos que suena bien, pero ¿cómo se traduce en la práctica? ¿Cuáles son las cosas que buscamos cuando fusionamos pares que dan al proyecto lo que es? Discutamos los valores fundamentales. Entonces, lo primero que hay que darse 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. Yarn no es una excepción. Para ayudar un poco, confiamos mucho en nuestros colaboradores para que sean los cambios que quieren ver, para contribuir de vuelta al proyecto que les gusta. En la práctica, esto significa que nuestro equipo principal 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 a partir de fuentes. Así que puedes probar fácilmente características independientes. Incluso puedes escribirlas tú mismo y comenzar a usarlas en tu proyecto sin tener que esperar a que se fusionen. Yarn se trata de hacer posible que experimentes mucho más allá de lo que podríamos ofrecerte por nosotros mismos. El segundo valor muy importante que siempre tenemos en cuenta al desarrollar en Yarn es la solidez. Yarn debe decirte si algo está mal en tu aplicación. No debe pasarlo por alto. No debe hacer suposiciones no controladas. Esto puede sonar un poco rígido y es la razón por la que tienes tantos problemas con x depende de y sin listar sus dependencias, pero es realmente crítico. Porque ya sea que modifiques aplicaciones o bibliotecas, necesitas tener confianza en que algo que funciona ahora también funcionará en producción o cuando sea instalado por tus clientes. Si algo necesita romperse, entonces debe romperse temprano para que no lo encuentres más adelante cuando estés

no está preparado para ello. Buenas prácticas. El panorama de JavaScript es amplio, cambia rápidamente y cuenta con muchas personas con opiniones. Como gestor de paquetes, estamos en una posición única para ayudar a nuestros usuarios a comprender las herramientas que están utilizando y guiarlos por el camino correcto. 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 proceso. Llegamos al último en este conjunto, la experiencia del desarrollador, haciendo lo correcto por defecto. Veamos un ejemplo. En Yarn 1, había un comentario llamado Yarn Check. Validaba que el proyecto estuviera instalado correctamente. Como resultado, varias empresas tenían una política de llamar a Yarn Check después de cada instalación, solo para asegurarse de que todo estuviera bien. Eliminamos este comentario de Yarn 2, ¿puedes adivinar por qué? La cosa es que Yarn debería hacer y ya hace lo correcto por defecto. No deberías tener que validar que tu proyecto esté instalado correctamente, porque debería estar correctamente instalado desde el principio. Así que hemos visto un poco de lo que Yarn pretende ser. Hablemos un poco de DevOps. ¿Qué puede hacer Yarn por ti, en términos prácticos? Vamos a repasar dos historias interesantes de proyectos que lo adoptaron. Uno es un proyecto de código abierto web del que es posible que hayas oído hablar. El otro es una aplicación interna. Sin sorpresa, el primero es Yarn en sí mismo. Antes de sumergirnos, déjame contarte una historia divertida. En Yarn 1, en realidad no usábamos espacios de trabajo para desarrollar Yarn, y fue un problema real porque no solo los errores estaban ocultos para nosotros, sino que tampoco nos enfrentábamos directamente al valor de algunas características importantes. Por ejemplo, cuando usas espacios de trabajo, es muy evidente que necesitas poder ejecutar un script en todos tus espacios de trabajo a la vez. Sin embargo, como no usábamos esos espacios de trabajo nosotros mismos, no parecía ser un gran problema en ese momento, y por lo tanto, la característica tardó mucho tiempo en llegar. Hoy en día, tenemos una regla interna de que el equipo de Yarn debe utilizar todas las características integradas en el núcleo, y creo que eso tiene un impacto positivo en el trabajo que hemos realizado hasta ahora. Esta es una de las razones por las que el repositorio de Yarn es tan importante para nosotros, porque es donde experimentamos con muchas características, no todas ellas utilizadas por nuestros propios usuarios. De todos modos, hablemos de flujos de trabajo. El primero son los ciclos de lanzamiento. Nuestro proceso anterior era muy sencillo. Teníamos un archivo en la raíz del repositorio, y se esperaba que cada PR tuviera una línea en él. Funcionaba bien, pero después de cambiar a un repositorio de modelo, no habría escalado muy bien, ya que necesitábamos la capacidad de lanzar cada flujo de trabajo por separado. Así que desarrollamos el flujo de trabajo de lanzamiento. La idea es que con cada PR que fusionamos, debe incluir un pequeño archivo creado por Yarn que enumera todos los espacios de trabajo que han sido modificados por el PR y si necesitarán formar parte del próximo lanzamiento, y si será una versión menor, una corrección o una versión mayor. Nuestro CI validará que este archivo exista y su contenido, y en el momento del lanzamiento solo necesitamos decirle a Yarn que agregue todos los archivos de versión actualmente verificados dentro del repositorio en paquetes y generación de registros de cambios del paquete.

Otro flujo de trabajo que estamos utilizando son los Zero-installs. La idea no es tan complicada. Simplemente decidimos mantener la caché del proyecto dentro del propio repositorio. Por lo tanto, para cada paquete que tenemos, mantenemos exactamente un archivo zip en el repositorio. Como resultado, cualquier persona que cargue el proyecto puede comenzar a trabajar en Yarn al instante. Ni siquiera tienen que ejecutar Yarn install. Más importante aún, significa que nuestros colaboradores pueden cambiar de una rama a otra casi sin costo en términos de cambio de contexto. Esto es extremadamente valioso porque está relacionado con el tema de experimentación FAPR del que hablé anteriormente. Podemos iterar rápidamente en diferentes ramas sin tener que pagar los costos cognitivos de tener que ejecutar instalaciones frecuentes cada vez que ejecutas git checkout. Debo mencionar que agregar los paquetes de la caché al repositorio es un compromiso que hicimos para nuestro proyecto, pero no es algo que absolutamente tengas que hacer tú mismo si no estás convencido con la idea. Sabemos que algunos otros proyectos han decidido ejecutar Yarn install como solían hacerlo y eso está perfectamente bien. Simplemente ahora tienes la opción. Un problema cuando tienes muchos espacios de trabajo, y nosotros 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 estén alineados en su configuración. Por ejemplo, ¿cómo asegurarse de que no haya dos espacios de trabajo que dependan de diferentes versiones de la misma dependencia? Puede convertirse en una tarea desalentadora y las herramientas existentes no ayudaron mucho con eso. Ahora, gracias a la función de restricción en el núcleo de Yarn, podemos aplicar patrones de períodos pasados en todos los espacios de trabajo en muy pocas líneas. Mejor aún, Yarn puede aplicar las correcciones por sí mismo. Por ejemplo, en el propio repositorio de Yarn, estamos utilizando esa función, no solo para garantizar que todas las dependencias de todos los espacios de trabajo sean las mismas, sino también para asegurarnos de que, por ejemplo, la licencia esté configurada correctamente en todos nuestros paquetes, que los scripts de compilación sean consistentes, entre otras cosas. Estos tres ejemplos te dan una buena idea del valor que los proyectos pueden obtener de Yarn. En general, ya no necesitan herramientas como learner o churn sets, ya que estos flujos de trabajo ahora reciben soporte de primera mano. Pero los proyectos de InterLab también pueden beneficiarse de Yarn, como veremos a continuación.

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 también ocupa un lugar central en el motor, y vamos a ver tres ejemplos. Si no sabes qué es Datalog, estamos creando un monitoreo en la nube realmente bueno, extrayendo señales de métricas arbitrarias. Dado este DMA, no te sorprenderá saber que también monitoreamos la forma en que nuestros desarrolladores interactúan con nuestra propia infraestructura, 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 envía todo al panel de control. Todos estos datos nos ayudan a identificar posibles cuellos de botella antes de que se conviertan en un problema y, en general, nos ayuda a priorizar nuestro trabajo. Como vimos con el propio repositorio de Yarn, registrar dependencias tiene un efecto negativo en la capacidad de contribuir eficientemente a un proyecto. Pero incluso en entornos corporativos, este patrón tiene su utilidad. Según nuestros datos, el registro remoto se cae aproximadamente una vez al mes. Al mantener nuestra propia copia de los paquetes, nunca nos bloqueamos durante nuestras implementaciones.

Además, a pesar de un alto volumen de commits, nuestra CI no pierde mucho tiempo ejecutando instalaciones. En resumen, en lugar de tener que pasar minutos instalando proyectos en cada CI individual, ahora es realmente cuestión de segundos. Y un último punto que quiero mencionar. Tenemos muchos proyectos y muchas dependencias. Algunas de ellas son errores y tratamos de abordar ellos lo mejor que podemos. Pero hasta que las correcciones se fusionen en el proyecto principal y se publiquen, lo cual a veces es un poco difícil, necesitamos una forma sencilla de usar nuestros cambios localmente manteniendo cierta auditabilidad. Algunas herramientas de terceros existen solo para eso. Pero YARN ahora lo admite de forma nativa gracias al protocolo de parche de una manera que está directamente integrada con el sistema de caché y todos sus componentes. Así que es realmente bueno tener esta característica que proviene de la comunidad a través del paquete de parche, por ejemplo, publicado en NPM que se mueve como una característica de primera mano directamente integrada con el gestor de paquetes.

Creo que estos tres ejemplos te dan una buena visión general de lo que YARN tiene para ofrecer en el contexto de una empresa. Pero ten en cuenta que estos son solo ejemplos. Por ejemplo, no hemos hablado de cómo YARN puede mantener tus paquetes comprimidos en disco y compartirlos entre proyectos. Eso es lo que prefieras. O cómo puedes instalar paquetes directamente desde Git o cómo tus scripts son portátiles tanto en Windows como en POSIX sin que tengas que hacer nada. Y eso es solo una lista rápida de una sola diapositiva. Hay muchas más joyas ocultas en YARN. Hasta ahora hemos discutido qué es YARN y 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. Vamos a sumergirnos rápidamente en el proceso de desarrollo de YARN en sí mismo. Una gran parte de nuestra `salsa secreta`, por así decirlo, es 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á mucho más allá del estándar de la industria, y la gran razón de ello es que hemos invertido muchos recursos

solidificando nuestras bases. 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 populares de terceros del ecosistema, como NextGIS, CreateRack, Gatsby, Angular, Jest, solo por mencionar algunos de los nombres importantes que monitoreamos. Si alguno de ellos envía accidentalmente algo incompatible con YARN o 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. Incluso si es un escenario poco común, tener este mecanismo en su lugar significa que podemos permitirnos ser un poco menos conservadores de lo habitual. No tenemos que asumir que nuestro trabajo es compatible con el ecosistema. Tenemos la prueba de que realmente es el caso. Y de manera similar, hicimos un gran esfuerzo para construir nuestra base de código utilizando las últimas herramientas disponibles, incluido TypeScript en sí mismo. No puedo enfatizar lo suficiente el beneficio que nos brindó. No solo nos evitó cometer errores tontos en nuestras propias PR, sino que también aumenta la confianza de que una PR no tendrá efectos imprevistos, lo que significa que nos resulta más fácil fusionar las solicitudes de extracción de colaboradores externos y confiar en que todo funcionará correctamente. Finalmente, nuestro último cambio importante también vino con otra regla de nuestra estrategia de pruebas. En ese momento, teníamos una serie de pruebas unitarias donde instanciábamos muchas clases del núcleo y activábamos sus métodos para cambiar sus comportamientos. Si bien funcionó lo suficientemente bien durante un tiempo, este enfoque resultó muy difícil de mantener a lo largo del tiempo, porque significaba que las refactorizaciones eran prácticamente imposibles, ya que habría sido necesario reescribir todas las pruebas, todo para mantener una interfaz desactualizada solo para las pruebas. Así que decidimos probar algo un poco diferente, a partir de la versión 2. Aún tuvimos que volver a escribir todas las pruebas, desafortunadamente, y tuve que hacerlo de manera incremental, pero esta vez las actualizamos para usar directamente el binario de la CLI, exactamente como lo harían los usuarios reales. Y debido a que la interfaz de la CLI no está destinada a cambiar realmente, significó que pudimos eliminar muchas habilidades mentales al tiempo que facilitamos a nuestros colaboradores externos comprender cómo escribir pruebas, porque literalmente todo lo que tienen que hacer es escribir código de la CLI. Creo que la lección aquí es simple. Para escribir código de manera eficiente a gran escala, como en un proyecto de código abierto importante, debes poder confiar en tu infraestructura. Y al aceptar pagar los costos por adelantado como lo hicimos, podrás alcanzar una velocidad de iteración más rápida y disminuir el riesgo de agotamiento para tu equipo, porque tendrán menos trabajo y menos presión para

suponer que las cosas funcionan. Así que centrémonos en YARN en sí mismo, y más precisamente, en una parte en particular, que es la arquitectura. Como mencioné anteriormente, YARN solía ser un monolito. Los espacios de trabajo no existían al principio, por lo que no los usábamos. Y aunque trabajamos en YARN, algunas partes de la aplicación se beneficiarían de ser independientes del resto, incluso si solo es para evitar que dependan accidentalmente de componentes no relacionados de los que no deberían ser conscientes. Entonces, una de las primeras cosas que hice al trabajar en ello fue cómo hacer que YARN fuera modular.

En la actualidad, tenemos un núcleo que contiene todos los algoritmos críticos. Por ejemplo, el resolutor, que toma todos los paquetes, consulta el registro de npm y obtiene todas las versiones necesarias, o el fesher que descarga paquetes y que expone una serie de interfaces que los modelos pueden implementar cuando lo deseen. La mayoría de las características que ves en YARN se implementan de esta manera. La comunicación con el registro de npm es un modelo. La generación de la tabla de paquetes es un modelo. El plug and play en sí mismo, que quizás conozcas como la nueva estrategia de instalación en YARN, es un modelo externo en sí mismo. Solo en el momento de la publicación, esos modelos se agrupan para generar una CLI de YARN que conoces. Curiosamente, esta arquitectura también facilita la ampliación de YARN con nuevas funcionalidades. Por ejemplo, el comando focus tal como lo implementamos es literalmente cien líneas dentro de su propio modelo. Podrías implementarlo tú mismo, y de hecho algunas personas lo han hecho. Porque eso es algo interesante, a veces es muy difícil construir flujos de trabajo que satisfagan a todos. Por ejemplo, tenemos dos miembros de la comunidad que han creado sus propios complementos que hacen exactamente lo que pretenden hacer con su instalación enfocada. Eliminan dependencias si no las desean. Generan un archivo zip que pueden publicar en AWS de una sola vez. Es mucho más fácil implementar tus propios flujos de trabajo en algunos casos que esperar que una herramienta de código abierto implemente exactamente lo que necesitas. Entonces, si un comportamiento no cumple con tus expectativas, puedes experimentar con uno nuevo y hacérnoslo saber. Como mencioné, en los últimos meses, al menos dos miembros de la comunidad han comenzado a resolver sus implementaciones de monorepos modificando complementos dedicados a su caso de uso. Entonces, ¿dónde vemos a YARN en el futuro? Nadie puede predecir lo que va a suceder, pero ya puedo decirte lo que está sucediendo actualmente. Estamos trabajando en la próxima versión principal de YARN, que será YARN 3. Tendrá sus mejoras, corregirá algunos comportamientos de nuestra CLI y agregará nuevas características, incluyendo algunas que seguramente tendrán sentido. Al mismo tiempo, estamos comenzando a explorar programas de patrocinio para hacer que YARN sea sostenible. Mencioné anteriormente que en los proyectos de código abierto, hay muchos esfuerzos, recursos y tiempo que necesitamos encontrar formas de apoyar este trabajo. Aquí es donde puedes hacer algo. Si tú o tu equipo están interesados en que tu empresa patrocine parte del tiempo que dedicamos a YARN, contáctanos. Estaremos encantados de discutir cosas que sean favorables para ambas partes.

Todo esto para decir que YARN está muy vivo y en mejor forma que nunca antes. Nuestro equipo está alineado. Nuestros objetivos son claros y nuestra tecnología es sólida. Ciertamente, hemos tomado un rumbo más optimista de lo que solíamos hacer. Y creemos que, para la mayoría de las personas, será un resultado positivo neto, sabiendo que la herramienta te protegerá de tus errores. Por supuesto, diferentes personas pueden preferir diferentes tipos de herramientas. Y eso está bien, porque no hay un proyecto que sea para todos. En general, creo que está claro que YARN está aquí para quedarse. No es solo una moda pasajera. Y realmente creemos que ofrecemos algo lo suficientemente diferente como para proporcionar valor al ecosistema. Hemos estado en relación con muchos proyectos durante los últimos años, ajustando nuestras copias, expandiendo conceptos y promoviendo buenas prácticas. Y creo que eso realmente ha tenido un impacto. Cosas como Next.js, Gatsby, Creative app, webpack, y muchos más. Cuando comenzamos, las pruebas que mencioné anteriormente, esas pruebas de extremo a extremo que ejecutamos en todos los proyectos cada cuatro horas, a menudo fallaban debido a dependencias faltantes. Cada vez que sucedía, íbamos al proyecto relevante y compartíamos un PR con ellos para tener esas dependencias faltantes. Con el tiempo, comenzaron a prestar más y más atención a esto. Y hoy en día, nuestro conjunto de pruebas rara vez informa problemas. Esto también es el trabajo que hace Yarn. No solo creamos una herramienta CLI. También hacemos que el ecosistema se mueva en la dirección correcta, no solo para los usuarios de Yarn, sino para todos los usuarios de administradores de paquetes. Por supuesto, el problema es que no siempre es visible o llamativo. Así que a veces puede ser difícil para los externos tener alguna idea de la cantidad real de trabajo que ponemos en el proyecto, pero es algo que realmente es importante para nosotros y que seguiremos haciendo en el futuro.

Así que hemos llegado al final de esta presentación. Espero que la hayas disfrutado. Y estaré encantado de responder a las preguntas que puedas tener sobre este tema. Gracias. Muchas gracias por esa increíble charla, Mal. Realmente la disfruté mucho. Me encanta escuchar sobre yarn, sobre de dónde viene, y el futuro de hacia dónde se dirige. Recuerda, si tienes alguna pregunta, escríbela en el chat para que podamos

Podemos obtenerlos. Y podemos preguntarle a Mal. Voy a invitar a Mal. Pero lo primero de lo que vamos a hablar son los resultados de la encuesta. Entonces, la pregunta de la encuesta fue, ¿por cuánto tiempo has estado usando Yarn? Y la respuesta más común fue de uno a tres años, seguida de menos de un año. Así que hay bastantes nuevos adoptantes, solo unas pocas personas que lo han estado usando por un tiempo. ¿Te sorprende eso, Mal, en absoluto? No, en realidad, es muy interesante, porque escuchamos de vez en cuando que la mayoría de las personas que usan Yarn lo han estado usando por un tiempo. Pero es interesante ver que casi la mitad de las personas que respondieron, respondieron menos de un año y el resto está en el rango de uno a tres años. Así que Yarn no es tan antiguo todavía. Tres años, uno a tres, puede ser mucho tiempo. Pero estoy realmente interesado en la parte de menos de un año. Es realmente interesante. Bueno, quiero decir, es bueno tener tantas personas que comienzan a usarlo y adoptarlo. Tenemos un par de preguntas que han llegado al chat y probablemente algunas más que vendrán. Voy a elegir una que realmente me gusta porque me encanta ver cuántas personas trabajan en diferentes proyectos de código abierto o proyectos grandes. Y siempre me pregunto, ¿cómo lo lograron? ¿Y cómo te involucraste en el mantenimiento del proyecto Yarn? Bueno, en ese momento fue porque me uní a Facebook. Así que me uní sin ninguna razón en particular relacionada con Yarn en sí. Y luego resultó que estaba en el mismo país que el equipo a cargo de Yarn en ese momento. Así que me uní al equipo. Cuando digo equipo, era una cantidad muy pequeña de personas que estaban trabajando en Yarn en sí. De hecho, cuando me uní al equipo, había solo una persona que rápidamente pasó a otros proyectos en diferentes países. Así que de repente tuve que trabajar en Yarn por mi cuenta. Y me gustó. Realmente me gusta trabajar en un proyecto que todo el ecosistema puede usar. Fue muy difícil, debo decir, porque significaba que tenía que hacer mucho trabajo para el código abierto y priorizar correctamente el trabajo, dependiendo también de la empresa para la que estaba trabajando. Y creo que aprendí mucho que cuando dejé Facebook, hace un año y medio, dos años atrás, decidí seguir trabajando en ello. Y eso fue aproximadamente cuando comenzamos a lanzar las nuevas versiones de Yarn 2 y posteriores que todavía estamos manteniendo hasta el día de hoy con un nuevo equipo principal que está compuesto casi en su totalidad por nuevas personas que se unieron a partir de Yarn 2, excepto por mí, que pasé de Yarn 1 a Yarn 2. Eso es increíble. Y una cosa que encuentro tan interesante acerca de tu charla sobre Yarn es que parece que hay tanto que aprendí sobre lo que Yarn puede hacer y que no sabía, y se volvió mucho más. Me gusta lo que dijiste, donde no es solo un administrador de paquetes, es un administrador de proyectos. Pero ¿qué dirías que es lo más importante si tuvieras que responder esto en una pregunta en una respuesta? ¿Cuán diferente es Yarn ahora en comparación con cuando se lanzó por primera vez? Creo que Yarn es mucho más estable y confiable en términos de aspecto técnico, porque hemos puesto un fuerte énfasis en hacer las cosas cuando

sabemos que son correctos con seguridad. Por ejemplo, con la instalación predeterminada de Yarn, lanzamos un error cuando intentas acceder a paquetes que no están en tu dirección de paquete, para que no corras el riesgo de depender accidentalmente de los balances que faltarían en tu máquina. Así que realmente intentamos ayudarte a construir tu aplicación de manera sólida, algo similar a lo que hacen TypeScript y Flow. Y desde el punto de vista organizacional, es muy diferente a lo que era antes, porque antes era principalmente una sola persona, a veces dos, pero no por mucho tiempo, y era extremadamente agotador. Hoy en día, el equipo central está compuesto por, diría, cuatro principales colaboradores líderes y algunos otros que gravitan en el mismo círculo. Así que se siente mucho menos solitario trabajar en las empresas, eso es una gran mejora. En el código abierto, creo que la principal forma de mantener viva la llama es encontrando a todas las personas que comparten la misma pasión que nosotros, y creo que hemos comenzado a encontrar eso. Sí, me encanta el hecho de que hayas hablado sobre cómo tener diferentes personas en el equipo ahora para ayudarte debe hacerlo mucho, mucho más

una experiencia más agradable. Hay una pregunta aquí, y estoy bastante seguro de que es una pregunta que te han hecho una y otra y otra vez, así que lo siento. Me disculpo de antemano por hacer esto, pero ¿cuál es la mayor razón para usar YARN en lugar de NPM? Desde mi perspectiva, hay muchas razones, pero diría que si algo funciona para ti, entonces está bien seguir usándolo, ya sea YARN o NPM. La razón por la que elijo trabajar en YARN es por su énfasis en la corrección. NPM tiene una filosofía ligeramente diferente, que es un poco que las cosas deberían funcionar y hacer algo sensato. Y en YARN hacemos algo un poco más radical en el sentido de que las cosas deberían funcionar si se supone que deben funcionar. Los dos enfoques tienen sus propios beneficios, pero creo que el que hemos elegido me conviene mejor a mí y también a nuestros usuarios. Me encanta esa respuesta. Muchas veces pensamos en esto como A versus B, cuando en realidad es como ¿prefieres un cuchillo o una cuchara? ¿Cuál prefieres? Dos herramientas tienen propósitos muy diferentes. Dependiendo de lo que prefieras, si prefieres que las cosas se desarrollen porque YARN y KLEM son organizaciones completamente diferentes. Pasan por el proceso de RSC, tenemos una forma más fluida y flexible de fusionar solicitudes de funciones. Esos son dos orbes muy diferentes. Genial. Esta es una pregunta, está un poco relacionada con NPM y me parece interesante, desde una perspectiva de desarrollo y alguien ha preguntado si compartes una hoja de ruta de funciones con el equipo de desarrollo de NPM o si simplemente desarrollas tus funciones de forma independiente y a veces coinciden de manera casual o son muy diferentes. No compartimos una hoja de ruta con ellos y no, debería reformular eso. A veces se nos ocurren ideas sobre nuestro gestor de paquetes y luego hay dos opciones diferentes. O bien esta función es exclusivamente para yarn en el modo cliente, por ejemplo, eso serían los espacios de trabajo que son algo que solo afectará a tu proyecto, entonces no necesitamos mencionarlo al equipo de NPM porque no les afectará directamente. Sin embargo, a veces podemos proponer ideas que afectarían al ecosistema, por ejemplo, eso sería nuestra RFC que propuso una forma de tener diferentes variantes del mismo paquete para diferentes arquitecturas para que estén precompilados en todas las arquitecturas al mismo tiempo. Algo así afectaría a los otros gestores de paquetes por lo que cuando eso sucede, generalmente contactamos a los mantenedores de ambos gestores de paquetes, npm pero también pmpm para obtener sus comentarios. Históricamente ha sido difícil estar siempre alineados en las funciones que cada uno quiere implementar, por eso implementamos más funciones divertidas que están en el cliente en sí en lugar de en todo el ecosistema. Pero a veces sucede, por ejemplo, un ejemplo de tal colaboración ha sido las dependencias de pares opcionales que propusimos hace dos o tres años y que discutimos con pmpm y npm y finalmente se implementaron en todos los gestores de paquetes. Así que todo eso tiene mucho sentido y también creo que es realmente importante que en ocasiones necesitemos esa colaboración para que todos avancemos y tengamos mejores productos y creo que poder colaborar y ser honestos como desarrolladores de JavaScript lo vemos todo el tiempo en la web donde se hacen propuestas y todos están al tanto de ello y cómo todos pueden implementar estas nuevas mejores prácticas o estas nuevas cosas buenas en la forma en que construyen cosas. Así que realmente realmente La pregunta era qué funciones vendrán en el futuro para Yarn pero también me gustaría agregar un poco más de emoción a esa pregunta, ¿cuáles son las funciones que vendrán en el futuro para Yarn que te emocionan más? La que más me emociona eso, pero llevará mucho tiempo estar realmente allí es poder instalar paquetes de diferentes lenguajes, actualmente Yarn puede instalar paquetes de Javascript pero estamos viendo un poco más allá de eso. Queremos que Yarn sea un gestor de paquetes que puedas usar para preparar un proyecto independientemente del lenguaje que estés usando en este momento. Puede ser Javascript, puede ser Python, puede ser otra cosa. Entonces, una gran parte de la arquitectura que decidimos para Yarn 2 ha sido hacer posible más adelante comenzar la investigación y el desarrollo para poder instalar paquetes de otros lenguajes. Por supuesto, no es fácil, ni técnicamente ni políticamente, porque esos lenguajes tienen sus propios gestores de paquetes por lo que no queremos causar problemas en ese sentido. Será un proceso lento pero realmente queremos encontrar una forma de hacer que Yarn sea universal en términos de gestión de paquetes. ¡Guau, eso me sorprende, poder usar paquetes de diferentes lenguajes! ¡Ahora ya estoy empezando a pensar en cómo sería eso! Debe ser tan ambicioso y en realidad una buena pregunta que se me ha ocurrido es, ¿cómo se te ocurren las ideas para las funciones? Entonces, ¿cuál suele ser la mayor inspiración para ti? ¿Son cosas que les suceden a ustedes como desarrolladores o son cosas que les interesan de la comunidad, de dónde obtienen algunas de las ideas que se convierten en funciones en YARN? Es un poco de ambas cosas. Por ejemplo, cuando comenzamos a trabajar en YARN 2, convertimos nuestro repositorio en un monorepo. Así que mencioné en la charla que antes no era un monorepo así que lo convertimos en un monorepo y comenzamos a usarlo y rápidamente nos dimos cuenta de que algunas cosas faltaban un poco porque las necesitábamos nosotros mismos y si las necesitamos, es probable que muchas personas también las necesiten. Entonces, en este caso, podemos detectar fácilmente un punto faltante y implementarlo porque nos beneficiaremos de eso nosotros mismos y luego se extenderá a la comunidad. En otros casos, proviene de la comunidad que presenta sus propios casos de uso y una cosa que hicimos en la versión 2 es crear un complemento de Yarn para permitirles implementar este tipo de funciones porque un problema que teníamos en Yarn 1 era que estábamos obligados a implementar todo lo que se nos proponía porque de lo contrario estábamos bloqueando el trabajo de varias personas. No queríamos que eso sucediera con Yarn 2, por eso tenemos este sistema de complementos que permite a la comunidad realizar su propia investigación y desarrollo para crear sus propios conceptos y si realmente son útiles para una gran cantidad de personas, entonces podemos incorporarlos al núcleo fácilmente. Así que es un poco de ambas cosas. Genial, me encanta eso, sé que se nos acaba el tiempo pero realmente quiero saber si hay alguien que es un desarrollador que ha estado pensando en comenzar con Yarn o qué les dirías o tal vez si hay algo que realmente quieres que todos los desarrolladores comiencen a hacer cuando trabajen con paquetes tal vez algo que simplemente haga que el mundo del desarrollo sea mejor, ¿cuál es una buena práctica que quieres que las personas adopten? Enumera correctamente tus dependencias, no asumas simplemente que algo funciona porque se supone que debe funcionar. A veces las cosas funcionan por casualidad y también es importante estar abierto a el hecho de que realmente tienes que respetar los estándares para tener un programa que funcione correctamente. Eso tiene mucho sentido, muchas gracias por pasar tiempo con nosotros hoy, realmente te aprecio, ¡gracias y adiós! ¡Gracias!