La filosofía de Yarn

Y ahora, hablemos de React. Estamos ofreciendo artículos gratuitos, videos, cursos y tutoriales para ayudarte a aprender todo sobre React. Introducido en 2011, el marco de trabajo se ha vuelto esencial tanto para los desarrolladores web como móviles, permitiendo aplicaciones modernas en apariencia y funcionalidad. Y aunque otras herramientas de JS han expandido o revisado sus nociones originales, la popularidad de React sigue siendo la que hay que superar

¿Sabías que TypeScript te permite escribir JavaScript de la manera que realmente deseas? Explora la variedad de cursos de TypeScript que hemos recopilado de nuestros oradores y colaboradores y descubre qué puedes hacer con este lenguaje y cómo mejora la experiencia de desarrollo ¿Sabías que TypeScript te permite escribir JavaScript de la manera que realmente deseas? Y ahora, hablemos de React.

Hola a todos, mi nombre es Mael y hoy vamos a hablar un poco sobre Yarn. Permítanme contarles un poco sobre quién soy. Trabajo para las redes sociales japonesas y trabajo en Datadog como parte del equipo de eficiencia de desarrollo. Nuestro trabajo es asegurarnos de que los desarrolladores que trabajan en Datadog, los desarrolladores de productos, puedan centrarse en escribir productos y no tener que lidiar con el mantenimiento de herramientas, infraestructura o implementaciones.

Como parte de eso, también he estado contribuyendo al gestor de paquetes Yarn y, de hecho, liderando su desarrollo desde 2017. Permítanme hacerles una pregunta para esta charla. ¿Cómo evalúan los proyectos? Todas las herramientas tienen sus fortalezas y debilidades, y es su trabajo, como desarrolladores, decidir cuál quieren usar en un proyecto para beneficiar al proyecto en sí. Y como mantenedores de proyectos de código abierto, nuestro trabajo es brindarles toda la información que necesitan para tomar una elección consciente que les permita avanzar en sus implementaciones.

Para hacer eso, podría decirles la lista de características de Yarn. Pero no creo que sea tan útil como muchas personas lo hacen parecer. De hecho, una lista de características es transitoria, es solo un punto en el tiempo. Si les dijera la lista de características de Yarn, todas las cosas buenas que puede hacer por ustedes, rápidamente se volvería obsoleta cuando implementemos nuevas. De hecho, estamos trabajando en Yarn 4. Como pueden imaginar, vendrán cosas nuevas en la próxima versión. En lugar de hacer eso y hacer que esta charla quede obsoleta mientras la pronuncio, nos vamos a centrar en el proyecto en sí y cómo funciona, por qué Yarn prospera, por qué seguirá haciéndolo en el futuro, ¿por qué es una apuesta segura para su proyecto? Eso es lo que creo que sería interesante discutir.

Para hacer esto, recordé algo llamado el Zen de Python. Es posible que no lo sepan, pero en Python, si hacen un tipo especial de importación, obtendrán un poema impreso en la pantalla. Puse las líneas allí, como `lo bello es mejor que lo feo`, `lo explícito es mejor que lo implícito`, `lo simple es mejor que lo complejo`, ya ven la idea. La idea es que todas esas declaraciones son en realidad la filosofía del código Python. Si escriben código Python, se supone que debe ser simple en lugar de complejo, se supone que debe ser plano en lugar de anidado, ese tipo de cosas. Me gusta mucho este formato y me pregunto cómo se vería si estuviera en Yarn. Escribí esas declaraciones. Las dejaré en pantalla durante unos segundos, pero no tienen que leerlas, las vamos a repasar una por una, así que no las lean, solo hagan una captura de pantalla si quieren.

Ok, empecemos. Pero antes de comenzar, una última cosa. Yarn estará aquí durante los próximos 10 años, ese es nuestro objetivo. Por lo tanto, todas las diapositivas que voy a mostrar deben ponerse en este contexto. Estamos trabajando en este proyecto no solo para que sea genial ahora, sino también para que siga siendo genial en el futuro. Primera declaración. Uniformidad es mejor que la variabilidad.

La uniformidad es mejor que la variabilidad. Nuestra CLI completa solía tener convenciones muy diferentes de un comentario a otro. Por ejemplo, teníamos una opción llamada Noble Links, otra llamada Ignore Scripts, otra Disable PMP, y eso solo para las banderas de la CLI. Las configuraciones en sí mismas tenían convenciones diferentes en cómo se llamaban las configuraciones. Todo esto dificultaba mucho recordarlas, incluso para nosotros. Para nuestros usuarios, era aún peor. Al hacer eso, también aumentaba la posibilidad de que se produjeran más desviaciones porque las personas que contribuían al código base de YARN no tenían idea de cómo debían llamar las cosas. No tenían idea de la nomenclatura correcta.

Por lo tanto, ahora estamos haciendo nuestro mejor esfuerzo para asegurarnos de que todas las banderas, todas las configuraciones, todos los comentarios tengan una nomenclatura consistente para que todo esté ordenado y claro.

Estable es mejor que inestable. Queremos que tu aplicación tenga solo dos estados, en lo que a nosotros respecta. O funciona en todas partes o se bloquea en todas partes. Por supuesto, puede ser difícil lograr eso en todos los casos, pero realmente hacemos nuestro mejor esfuerzo para lograrlo. Por ejemplo, los scripts se ejecutan mediante una implementación compartidacross-platform. Entonces, incluso si estás escribiendo scripts que están destinados a ejecutarse en Linux y uno de tus colaboradores está trabajando en tu proyecto desde Windows, es muy probable que simplemente funcione, incluso si estás utilizando tuberías, incluso si estás utilizando redirección, porque Yarn aplica una indirección para que todo sea portátil. Otro ejemplo es que Yarn hará todo lo posible para mostrar errores tempranamente. Por ejemplo, supongamos que estás en producción, estás eliminando todas las dependencias, es muy probable que te falten algunas de ellas, debido al problema de elevación nula de dependencias fantasma, como se les llama. Yarn hará todo lo posible para informarte cuando eso suceda para que puedas solucionarlo. Te dirá `este paquete depende de algo pero no está instalado, por favor instálalo`.

Legible es mejor que desordenado. Como administrador de paquetes, tenemos mucha información que podemos proporcionarte. Pero solo algunas de ellas son realmente interesantes. Por lo tanto, hacemos un esfuerzo consciente para restringir la información que imprimimos en pantalla y solo mostrar las más importantes. Incluso más que eso, también estamos tratando de resaltarlas para que sean fácilmente legibles por un humano utilizando colores en lugares semánticos. Por ejemplo, todos los nombres de paquetes tienen el mismo color, todas las ramas tienen el mismo color, todas las referencias tienen el mismo color. Ves la imagen. Utilizamos colores no para embellecer las cosas, sino para darles un significado. Además, también nos importa mucho el espacio vertical porque no tengo un terminal muy grande por lo que realmente es un problema cuando, por ejemplo, ejecutas una instalación, tienes, digamos, 300 líneas de tonterías que se imprimen en pantalla. Eso es algo que no queremos que suceda. Realmente hacemos esfuerzos para asegurarnos de que ninguno de los PR que fusionamos tenga este tipo de problema.

Los errores son excelentes herramientas. No tengas miedo de ellos. Las advertencias son errores o formas de incluir al usuario en el proceso de toma de decisiones. Por lo tanto, no nos alejamos de imprimir errores. Cuando no estamos seguros de qué hacer, pedimos orientación y cuando algo no parece seguro, pedimos confirmación a través de configuraciones, por lo general. Pero deben ser accionables. Eso es lo importante acerca de los errores. Si imprimimos un error pero no tienes forma de solucionarlo, solo será frustrante para ti. Entonces, demasiados errores harán que nuestros usuarios los ignoren.

Cuando empiezas a tener errores en los que no puedes hacer nada al respecto, como advertencias de dependencias entre pares, simplemente dejarás de leerlas. Eso no es algo que queremos que suceda. Por lo tanto, tratamos de mostrar errores y advertencias solo si realmente puedes hacer algo al respecto.

Y para ayudarte con eso, tenemos una lista de todos los códigos de error en nuestro sitio web junto con explicaciones detalladas para cada uno de ellos. Son como pequeños artículos que explican cuál es el problema y cómo solucionarlo. Y frecuentemente mejoramos la redacción basándonos en los comentarios que recibimos de nuestros usuarios. Realmente hacemos esfuerzos conscientes para escribir algo legible.

Un poco es importante, los benchmarks no tanto. Los benchmarks suelen ser sobre gestores de paquetes olvidados. Hace años estaban en un lugar muy diferente. Muchos de ellos eran mucho más lentos de lo que son ahora, incluido YARN. Pero hoy en día la velocidad rara vez es el verdadero diferenciador entre ellos. YARN tiene benchmarks automatizados, que usamos para detectar regresiones dramáticas, si eso sucede. Y como ejemplo de por qué los benchmarks no son la única... no son la mejor manera de ver qué tan bueno es un gestor de paquetes, el mismo benchmark que usamos nosotros mismos en nuestro CI no da los mismos resultados si los ejecutamos en el CI o en laptops. Así que es realmente difícil determinar un ganador en términos de velocidad hoy en día, porque realmente depende no solo de los gestores de paquetes en sí, sino también del entorno en el que se ejecutan. En general, la velocidad no es un objetivo en sí mismo. Es un medio para un fin. Hacemos esto por una razón. Hacemos esto para mejorar la experiencia del desarrollador, tu experiencia de usuario. Si bien la velocidad es algo que tenemos en cuenta, no es lo principal en lo que pensamos.

Nuestro objetivo es hacer lo correcto de forma predeterminada. Eso es algo que estamos empezando a adoptar cada vez más. Hasta ahora, Yarn era una herramienta regular y tenía el mismo comportamiento en todos los entornos, pero el problema es que configurar un gestor de paquetes es un poco difícil, especialmente si tienes en cuenta diferentes entornos, si tienes en cuenta la seguridad, ese tipo de cosas. Por ejemplo, ¿detectarías una solicitud de extracción que agregara una dependencia maliciosa a tu proyecto? Los llamados adictos a la cadena de suministro. No está claro. Pero ahora estamos tratando de hacer algo al respecto, por ejemplo, Yarn habilitará la bandera inmutable de forma predeterminada en CI para que no puedas confirmar un archivo de registro si no está actualizado. En la próxima versión principal, agregaremos verificaciones adicionales en las solicitudes de extracción cuando detectemos que una rama es una solicitud de extracción.

Esta es una afirmación interesante. Gran parte del comportamiento en Yarn se ha generado a partir de npm o Yarn 1. Y por ejemplo, ¿sabías que si un paquete tiene un archivo binding.jp, tiene una post instalación implícita. Incluso si no lo declara, Yarn y npm aún ejecutarán nodjp install solo porque siempre ha funcionado así.

A veces reevaluamos características y las modernizamos o las descontinuamos. En este caso, la post instalación nodjp se ha mantenido porque habría roto demasiadas cosas descontinuarla. Pero en otros casos, hemos decidido descontinuar algunas características. Por ejemplo, las dependencias de paquetes se descontinuaron hace algunos años y hemos estado bien sin ellas.

Decir que no es difícil y necesario. Muchas contribuciones que recibimos son únicas. No es un problema en sí mismo, pero tenemos que asumir que tendremos que mantener el código que estamos fusionando nosotros mismos. Dado que somos un equipo pequeño, eso ejerce mucha presión sobre nosotros. Necesitamos evaluar la utilidad, la complejidad y los costos de mantenimiento antes de decidir fusionar algo. A veces no se cumple el criterio y eso hace que la característica no sea elegible para su adopción central. Pero eso tampoco debería ser un obstáculo. YARN.NO proporciona ganchos que las aplicaciones pueden usar para implementar sus propios comportamientos. Por ejemplo, los complementos de YARN pueden crear comentarios. Pueden acceder a nuestras APIs, nuestras APIs de JS. Pueden trabajar con un proyecto. Pueden manipular dependencias. Pueden hacer todo tipo de cosas. Como tal, decir que no rara vez impide que una característica se desarrolle de forma independiente. Por ejemplo, un miembro de la comunidad creó un complemento que es básicamente para reemplazar Turbo u otras herramientas similares. Así que es realmente interesante ver lo que la comunidad crea simplemente usando complementos. Los usuarios son colaboradores, no clientes. La sostenibilidad del código abierto es un tema importante.

Quizás veas charlas sobre esto en el futuro. Como dijimos, no tenemos los recursos para investigar todo. No tenemos el equipo de soporte. No tenemos los recursos para tener largas conversaciones de ida y vuelta en solicitudes de soporte tratando de averiguar qué es único acerca de tu entorno, ese tipo de cosas. Lo que podemos hacer, sin embargo, es compartir contexto y mantener la base de código saludable para que puedas investigar tu problema tú mismo. Esa es la única forma en que podemos asegurarnos de que todos los errores puedan ser abordados. Al asegurarnos de que tienes la información que necesitas para profundizar en ellos si es necesario.

Y por supuesto, el lado positivo es que algunas personas que realmente se tomaron el esfuerzo de entender cuáles son sus problemas pueden convertirse a veces en colaboradores recurrentes y ayudarnos a mantener YARN. Esto ya ha sucedido. Trabajamos para el beneficio de futuros colaboradores. Así que recuerda lo que dije sobre YARN estar vivo durante 10 años. Hay algo llamado el factor de pulso. Si solo una persona está a cargo de un proyecto, entonces si esa persona desaparece, el proyecto tiene un gran problema. Y como dije, queremos que YARN sobreviva 10 años o más. No sé si en 10 años seguiré trabajando en YARN, pero sé que probablemente seguiré usándolo, pero ¿trabajando? No estoy seguro. Entonces, lo que haré, y lo que todo nuestro equipo está haciendo, es asegurarnos de que estamos invirtiendo en mantenimiento, para ayudar a las futuras generaciones de colaboradores.

De vez en cuando, estamos mejorando, por ejemplo, la experiencia de lanzamiento, para que muestre el botón en GitHub actions, la experiencia de fusión, para que podamos resolver automáticamente los conflictos con solo hacer clic en un botón en GitHub. Ese tipo de cosas. No es completamente desinteresado, porque cuanto más activos colaboradores tengamos, significa que tenemos más ancho de banda nosotros mismos, menos presión y más tiempo para dedicar a I+D y características divertidas y cosas así. Intentamos ser maestros y abogar por buenas prácticas. Hay una escuela que aconseja proteger a los desarrolladores de las consecuencias del uso incorrecto y siempre tratar de hacer lo que probablemente quieran hacer. Porque entonces, disminuye la barrera para usar la herramienta, y eso es algo bueno para los principiantes. Pero, hay otra escuela, y creo que estoy más en esta, que tiene como objetivo detectar errores temprano y explicar cómo no repetirlos. YARN se inclina más hacia la segunda opción. Es difícil saber exactamente qué quieren hacer los usuarios, así que en lugar de hacer suposiciones y equivocarnos, preferimos decirte lo que no funciona y luego tú puedes ver por ti mismo qué significa y cuáles son las formas de solucionarlo, según el contexto. Porque el contexto a veces puede cambiar cómo se supone que debes solucionar un problema. ¿Verdad? Eso es lo que hacemos. Beneficiar al ecosistema, no solo a los usuarios directos. Nuestro equipo ha hecho docenas, y cuando digo docenas, no estaba del todo seguro de si no deberían ser cientos, pero digamos docenas de palabras clave y comentarios para ayudar a mejorar proyectos de terceros. Hemos estado en todos los repositorios, hemos respondido preguntas. Y seguimos...

Y seguimos haciéndolo. Plug and play tiene efectos tangibles en las dependencias fantasma. Incluso si eres un usuario de NPM o PNPM, puedes agradecernos parcialmente por disminuir las posibilidades de dependencias fantasma, porque, nuevamente, hemos estado trabajando con proyectos de terceros para resolver sus dependencias faltantes. Cada vez que uno de nuestros usuarios nos dice `oye, Yarn está reportando un problema con este paquete`, lo revisamos y decidimos si fue un problema en Yarn o en el proyecto de terceros y discutimos con sus mantenedores. Y esto mejoró muchos paquetes en un tiempo dramáticamente corto. También abogamos por nuevas características en otros gestores de paquetes. Y a veces incluso las implementamos nosotros mismos. Como ejemplo, yo mismo implementé las dependencias pares opcionales en NPM hace años. Además, trabajamos con el proyecto Node. Por ejemplo, diseñé e implementé CorePack para Node, que se incluye tanto en Yarn como en PMPM con Node.js. También contribuimos al Grupo de Trabajo de Cargadores de Node.js. Para que la API de Cargadores, que es utilizada por cosas como Jest para simular módulos, sea lo más potente posible. Así que realmente estamos tratando de ser buenos ciudadanos de todo el ecosistema de JavaScript y no solo trabajar para mejorar nuestros proyectos, sino todo lo relacionado con JavaScript.

Para lograr eso, a menudo elegimos el destino e interpolamos el viaje. El ecosistema tiene muchos inquilinos y cada vez que quieres hacer algo, las mejoras a menudo deben ser planificadas a largo plazo, porque todos necesitan estar de acuerdo y al principio nadie está de acuerdo. Así que realmente necesitas discutir durante mucho tiempo para que las cosas se hagan realidad. Además, si arregláramos las cosas en la capa incorrecta, afectaría la mantenibilidad porque sería difícil eliminarlas una vez que ya no sean necesarias. Entonces, primero, lo que hacemos es descubrir cuál es la solución correcta, en un mundo ideal, sin importar cuánto tiempo lleve. Y decidimos cuáles son los caminos que queremos seguir para llegar allí. Si cometemos errores en el camino, corregimos la trayectoria según sea necesario, pero siempre teniendo en mente el final del viaje. Hasta ahora, ha funcionado bien. Por ejemplo, Plug and Play se ha desarrollado de esta manera. Sabíamos a dónde queríamos llegar y decidimos interpolar pasos intermedios, desde donde veníamos, para mejorar progresivamente la situación en las dependencias del juego.

Y finalmente, la última regla, pero la más importante. Si no es divertido, no lo estás haciendo bien. En realidad, esta regla es para nosotros como mantenedores. Si no es divertido, no lo estamos haciendo bien. Puedes recordar lo que dije sobre la sostenibilidad del código abierto. Es extremadamente importante que los mantenedores encuentren diversión en lo que están haciendo. Crea entusiasmo, crea energía. Es más divertido cuando no eres la única persona que lo hace. Mantener un proyecto puede ser difícil, estresante. Tenemos que recordar todos los días que lo estamos haciendo por nosotros. Si estoy trabajando en Yarn, lo siento, pero no es por ti. Es porque encuentro placer en hacerlo. Encuentro orgullo en hacerlo. Eso es algo importante de recordar cuando estás desarrollando un proyecto de código abierto. Y también es importante recordarlo como usuario. Porque también es una garantía de que seguiremos trabajando en este proyecto porque seguiremos encontrándolo divertido. Nos aseguramos de no agotarnos mientras trabajamos en él. Nuevamente, nos corresponde a nosotros mantener el ambiente lo más divertido y libre de toxicidad posible. Y lo estamos haciendo, estamos invirtiendo en ello y eso es algo que realmente tenemos en cuenta. Incluso si es la última diapositiva, es la más aplicable a todo el código abierto en general.

Espero que les haya gustado esta charla. Ahora vamos a hacer una breve sesión de preguntas y respuestas. Estaré disponible para responder sus preguntas. Ustedes preguntaron sobre la experiencia de contribuir a código abierto. Y los resultados están aquí. El 55% dice que no ha intentado contribuir a código abierto. El 36% lo disfrutó. Y para el 9% fue difícil. Entonces, ¿qué opinan al respecto? Creo que es súper interesante porque código abierto es una parte importante de ser un desarrollador hoy en día. Es bueno ver que muchas personas realmente intentan hacer una contribución y que les gusta. El 56% que aún no ha intentado es un número un poco alto. Y por eso, es parte del trabajo que estamos haciendo como mantenedores de muchos proyectos, tratando de reducir este número para que las personas puedan sentirse comprometidas con el proyecto que utilizan. Esos son números geniales. Me preocupa más este número tan bajo, pero para algunas personas, para él, fue difícil. Supongo que a veces puede ser difícil. Pero me alegra mucho que a la mayoría de las personas les haya gustado.

Sí, eso es genial. Nunca usamos ESLint en ninguno de mis procesos anteriores, pero teníamos convenciones de nomenclaturadocumentation como sí, ve, léelo y nómbralo de acuerdo a eso. Pero sí, a veces puede ser confuso documentation. Interesante, sí.

Gracias por responder eso. Espero que eso haya respondido tus preguntas, Darkovik.

Tenemos otra pregunta de Joseph Reed, y están preguntando tenemos docenas de desarrolladores contribuyendo a nuestro monorepo. ¿Se recomienda que todos usen la misma versión exacta de Yarn o debería importar eso? Sí, seguro. Aunque intentamos no enviar cambios que rompan entre versiones, excepto los mayores, por supuesto somos humanos y podemos cometer errores o corregir errores en los que confías o agregar errores en nuestras características o lanzamientos. Entonces generalmente lo que noté es que si todos tienen la misma versión exacta de un gestor de paquetes sea cual sea, entonces se garantiza que tendrán el mismo comportamiento exacto. Si hay diferentes versiones siempre habrá algo que será ligeramente diferente de un desarrollador a otro y aunque en general puede que no sea un problema será un problema en algún momento y causará una situación muy difícil de depurar que no quieres que suceda.

Entonces, con Yarn hasta hace un año teníamos la configuración de ruta de Yarn que te permitía verificar dentro de tu repositorio para que sea utilizado de manera transparente por cualquier persona en tu empresa y con Node trabajamos durante el último año para lanzar Core Pack que te permite hacer lo mismo pero sin verificar en Yarn dentro de tu repositorio. Solo tienes que establecer un campo de gestor de paquetes dentro de tu packet.json y si las personas instalaron Yarn usando Core Pack obtendrán la versión que describiste. Básicamente es una forma de bloquear la versión de tu gestor de paquetes. De acuerdo. Sí, eso es todo. Gracias por responder eso. Tenemos otra pregunta de Cici Miller. Una vez escuché decir que un buen gestor de paquetes te dirá la razón por la que no debes usar su producto. ¿Cuál sería tu respuesta a eso y cómo podemos ayudar a que esa respuesta desaparezca en la comunidad de código abierto? Esa es una pregunta interesante. Diría que Yarn es quizás un poco más decidido que otros gestores de paquetes. Realmente intentamos decirte cuando algo no parece correcto según nuestros estándares. Por ejemplo, cuando se accede a una dependencia pero no está listada te decimos que es un problema. En otros gestores de paquetes podría funcionar porque generalmente funciona hasta que deja de hacerlo. Yarn realmente maestra los errores temprano lo cual puede ser una fricción para la adopción porque algunos paquetes no están destinados a admitir este tipo de rigurosidad y hay trabajo por hacer. Eso es algo que mencioné en la charla que hemos estado haciendo con el ecosistema en su totalidad. Fuimos a un proyecto de terceros que tenía un problema con eso y lo discutimos con ellos, trabajamos con ellos para solucionar esos problemas en todos los casos que fueron una referencia para nosotros. Aún quedan algunos que quedan pero de vez en cuando tenemos la situación en la que necesitamos agregar un poco más de configuración para indicarle a YARN que algunas dependencias deben estar allí y que puede continuar. Entonces, en general, creo que la principal desventaja de YARN también es su mayor ventaja en el sentido de que somos muy estrictos y realmente queremos que tu proyecto sea consistente y tenga patrones seguros. Sí, la consistencia es definitivamente muy importante.

Entonces, bien, tenemos algunas preguntas genéricas. ¿Cómo logran encontrar nuevas ideas para mejorar? Tenemos un equipo de colaboradores. Por lo general, cualquiera de nosotros tiene ideas sobre cómo mejorar Yarn. Un proyecto de código abierto siempre tiene más ideas de las que las personas pueden trabajar. Por eso confiamos tanto en que las personas contribuyan al proyecto, porque nos ayuda a mejorar esas ideas locas que tenemos en mente y realmente queremos trabajar en ellas, pero aún no tenemos suficiente tiempo. Pero de vez en cuando, por ejemplo, en este momento estamos trabajando en Yarn 4, la próxima versión principal de Yarn. Así que nos tomamos el tiempo para hacer algunos experimentos más locos para ver qué podríamos mejorar. Por ejemplo, en Yarn 4 estaremos experimentando con el espejo sin conexión, tratando de deshabilitarlo de forma predeterminada en lugar de habilitarlo de forma predeterminada. También hemos estado experimentando con la división de paquetes en Yarn. Estamos tratando de disminuir el tiempo de ejecución de una lectura del binario de Yarn. Estamos haciendo mucho trabajo pequeño e interesante y generalmente tenemos una gran cantidad de tareas pendientes. Así es como lo hacemos. Eso suena interesante. Muy emocionante, para ser honesto. Tenemos una pregunta muy interesante de Sergio. Si pudieras rediseñar un sistema de dependencias desde cero, ¿qué cambiarías? Bueno, ya lo hice. En cierto sentido, trabajamos en Plug and Play, que es la estrategia de instalación predeterminada para los paquetes cuando se utiliza Yarn. Y aunque admitimos no-modernos y funciona mejor con Yarn 3 que con Yarn 1, Plug and Play es realmente la forma en que vemos cómo debería funcionar la resolución de dependencias. Básicamente, es solo un mapa de dónde están todos los paquetes en tu sistema y qué paquete depende de qué otro. En cierto sentido, es muy similar a los mapas de importación, si has oído hablar de ellos, excepto que está más integrado en Node. Por ejemplo, si estás accediendo a un paquete que no has listado, PMP es capaz de decirte cuál es el problema exacto. Por ejemplo, ¿es un paquete que no has listado? ¿Es una dependencia de igual nivel que no fue proporcionada por quien depende de tu paquete? ¿Es porque un paquete no se instaló porque es nativo y no coincide con el sistema actual? Entonces, lo que hicimos en PMP es la forma en que vemos cómo debería funcionar la resolución de dependencias. Aún no es el caso y estamos trabajando con Node para poder implementarlo oficialmente a través de cargadores, para que puedas utilizar la interfaz correcta. Pero, sí. Genial. Así que, ahora se nos está acabando el tiempo. Pero para la audiencia, aún pueden seguir haciendo preguntas en el canal de Discord y Mel las responderá. No hay un chat especial, pero asegúrate de hacer tus preguntas y él estará allí en Discord para responderte. Muchas gracias, Mel, por tu charla informativa y por responder todas estas preguntas. Gracias, Enerada. Fue un placer estar aquí.