Yarn 4 - Gestión Moderna de Paquetes

[♪ music sonando ♪ ♪ Hola a todos, mi nombre es Mael. Trabajo en Datadog. Y he estado liderando el desarrollo de Yarn durante los últimos años.

Así que hoy voy a hablarles un poco sobre Yarn, cuáles son sus valores fundamentales, lo que estamos buscando para cada versión que lanzamos y les mostraré un vistazo del futuro.

Antes de empezar, ¿qué es Yarn? Así que Yarn es un gestor de paquetes que quizás conozcan, similar a NPM, que les permite instalar paquetes en su sistema para resolver dependencias. Y favorece la consistencia y la estabilidad mientras aún intenta proporcionar buen rendimiento y alta modernidad a sus proyectos.

Ha sido una larga aventura, la primera versión de Yarn se lanzó hace casi seis años, con la 0.15, un año después lanzamos la primera versión estable con la 1.0, y dos años y medio después decidimos que era hora de hacer un cambio y decidir de una vez por todas lo que queríamos hacer en el futuro de Yarn, y con eso llegó la 2.0.

En ese momento, hubo muchas discussion sobre algunos de los aspectos fundamentales en los que hemos estado trabajando en el lanzamiento subsiguiente de la 3.0, y que vamos a seguir refinando en la 4.0.

¿Por qué otro gestor de paquetes? Ya tenemos MPM, también tenemos PMPM, ¿qué aporta Yarn a la mesa? Lo que hay que recordar, y eso es cierto para los gestores de paquetes, pero también es cierto para, digamos, los empaquetadores es que las características y los rendimientos aparte, cada proyecto en el ecosistema de código abierto ecosistema tiene diferentes propiedades en términos de prioridades, hoja de ruta, modelo de gobernanza, mantenibilidad, infraestructura. Todas esas cosas son cosas que debes tener en cuenta cada vez que intentas evaluar un proyecto. Porque por ejemplo, MPM es propiedad de GitHub, mientras que Yarn es completamente de código abierto. En ambos casos, hay pros y contras, y ese es el tipo de cosa que no ves a primera vista, pero que tiene sentido cuando estás tratando de invertir en una herramienta a largo plazo.

Así que hablé de prioridades. ¿Cuáles son las prioridades de Yarn? Tenemos cuatro de ellas en este momento. La última se añadió hace poco y vamos a hablar de ella en las próximas diapositivas, pero primero, la estabilidad es el principio fundamental de Yarn. Queremos que todas tus instalaciones, toda tu experiencia usando Yarn sea determinista y predecible. Si algo funciona para ti, entonces debería funcionar para tus colegas. Si algo falla para ti, entonces también debería fallar para tus colegas. Y esta última parte es bastante importante porque asegurarse de que un programa falla de manera consistente te permite asegurarte de que también funcionará de manera consistente. Si alguien tiene un problema, podrás reproducir el problema y ayudarles a superarlo. Mantenibilidad. Estamos tratando de configurar el proyecto no solo para que tenga éxito ahora, sino también para que tenga éxito en el futuro. La forma en que vemos Yarn, Yarn seguirá estando aquí en diez años. ¿Cómo podemos asegurarnos de que Yarn seguirá estando en buen estado en diez años? Eso no es tan fácil porque significa que tenemos que tomar decisiones en términos de gobierno, en términos de arquitectura de nuestro propio repositorio. ¿Cómo podemos mantener la base de código saludable? Así que esa es una de nuestras prioridades.

La modernidad es otra. En Yarn 1, notamos que muchos de ustedes tenían casos de uso muy específicos. Fue muy difícil para nosotros implementar todas las características que necesitaban, a veces que solo una empresa necesitaba. Así que en lugar de eso, lo que decidimos hacer con la versión moderna de Yarn es hacer nuestro núcleo modular. Lo que significa que puedes escribir plugins, puedes escribir comandos que se integran en la API central de Yarn que proporcionamos y que documentamos. Y puedes hacer tu propia lógica en unas pocas líneas simples de código. Casi todos los comandos de Yarn se implementan a través de este sistema. Por ejemplo, la instalación en sí misma toma algo así como 50 líneas para implementar. Y finalmente, seguridad. Eso es algo que estamos empezando a introducir, porque aunque Yarn era seguro antes en el sentido de que intentábamos prevenir que los paquetes accedieran a tu disco, hay otros tipos de ataques. Durante los últimos meses, es posible que hayas oído hablar de ataques como UAParser.js o Faker.js, este tipo de problemas que están empezando a surgir, y queremos proporcionar una solución para que no sea un problema en el futuro. Puede que te des cuenta de que no hablé de rendimiento. Eso es porque estamos en 2022.

Y a decir verdad, todos los gestores de paquetes tienen el mismo rendimiento para las mismas características. A veces un gestor de paquetes hará más cosas que el otro, por ejemplo, con Yarn estamos haciendo algunas validaciones. Pero en general, es lo mismo. Hacemos seguimiento de los benchmarks en PMPM, NPM, y Yarn. En nuestra infraestructura, de forma horaria. Y algo que noté al tratar de ver cuál era la diferencia entre los gestores de paquetes es que aunque PMPM tiene cierta ventaja sobre nosotros en nuestro benchmark automatizado, eso es algo que no pude reproducir en mi portátil. Creo que esto demuestra que los rendimientos de los gestores de paquetes son muy relativos y en el punto en el que estamos, no cambian muchas cosas.

De todos modos, basta de Perth. Quiero que aprendas algo sobre yarn. Así que ahora vamos a hablar de 14 cosas que no sabes sobre yarn pero que en realidad hace bastante bien. Así que, primero, sobre las instalaciones. Ya que eso es lo principal que hace un gestor de paquetes. No sé si lo sabes, pero incluso las versiones modernas soportan nonmodels perfectamente. Puede que recuerdes que en la 2.0 lanzamos una nueva estrategia de instalación llamada plug and play que te permite no tener una carpeta de nonmodules para compartir tus dependencias en todos los proyectos de tu máquina. Para no ser plagado por dependencias fantasma. Pero también soportamos nonmodules. Si tu objetivo es migrar un proyecto rápido y fácil, puedes hacerlo. Está muy bien soportado. Tenemos un protocolo llamado exec que te permite crear tus propios paquetes de forma dinámica al ejecutar tu propia instalación. El protocolo exec, por ejemplo, digamos que tienes un paquete que está en SVN. No sé si otras personas están usando SVN, pero a veces lo hacemos. Y si quieres obtener un paquete de allí, entonces tendríamos que implementarlo dentro del gestor de paquetes, así que dentro de yarn mismo. Con el protocolo exec, puedes simplemente definir un script de JavaScript que obtiene estos paquetes de cualquier ubicación que quieras. Yo uso SVN, pero podría ser de cualquier otra ubicación.

Cualquier espacio de trabajo puede ser instalado desde git. El protocolo git, al declarar una dependencia como git, te permite instalar un espacio de trabajo desde cualquier producto de Yarn o PMPM o NPM. Y finalmente, el protocolo de parche es un protocolo que te permite aplicar cambios a cualquier paquete y mantener esos cambios dentro de tu repositorio. Eso es un caso de uso muy común cuando tienes un problema de seguridad en un proyecto que necesitas solucionar y que aún no ha sido lanzado. Puedes simplemente usar el protocolo de parche para solucionar lo que sea problemático. Otro caso de uso es, por ejemplo, cuando estás intentando migrar de CGS a ESM, y hay algo que está rompiendo en algún lugar, solo una línea para cambiar, pero es difícil enviar un cambio aguas arriba, puedes usar el paquete de parche para simplemente saltar la línea que te está molestando.

Eso fue para las instalaciones. Ahora, Yarn tiene muchas características y algunas de ellas son opcionales. Puedes optar por ellas y empezar a usarlas, pero puedes ignorarlas completamente. La primera es que Yarn puede instalar enlaces simbólicos, al igual que pnpm. Puede que conozcas esta estrategia que tiene pnpm, donde en lugar de generar un non-model concreto donde cada archivo es realmente un archivo y cada carpeta es realmente una carpeta, npm hace enlaces simbólicos que apuntan a una tienda global. Eso es algo que Yarn puede hacer. Lo introdujimos en la 3.0 el año pasado y algunas empresas han empezado a usarlo y a darnos sus comentarios.

Lo que realmente me gusta de Yarn es que somos muy modulares, como mencioné. Así que podemos implementar muchas cosas en muy pocas líneas de code. Así que cuando implementamos el enlazador pnpm que te permite hacer esos enlaces simbólicos, en realidad tomó menos de 100 líneas hacer la primera iteración. Eso es lo que mencionaba cuando decía que queremos que Yarn sea saludable para que dentro de diez años podamos seguir añadiendo características, corrigiendo errores sin ser obstaculizados por las implementaciones pasadas.

Tenemos un flujo de trabajo de versiones que te permite gestionar versiones de espacios de trabajo cruzados. Así que si la única razón por la que estás usando, por ejemplo, learner es para gestionar versiones, eso es algo que puedes obtener gratis simplemente usando Yarn. Estamos usando este flujo de trabajo como parte del desarrollo de Yarn en sí mismo ya que todos nuestros espacios de trabajo, y tenemos muchos de ellos como 30 o algo así, todos nuestros espacios de trabajo son gestionados a través de este sistema. Así que lo estamos mejorando con frecuencia. Las restricciones te permiten vincular los paquetes y archivos de tu proyecto. Una vez que tienes una cierta cantidad de espacios de trabajo como, por ejemplo, Yarn con estos 30 y pico de espacios de trabajo, se vuelve difícil asegurarse de que todos ellos satisfacen algunos criterios que tienes, por ejemplo, que ninguno de ellos dependa de alguna dependencia, como, si tienes tanto Lowdash como Underscore, será un problema, así que podrías querer prevenir que uno de ellos sea añadido en algún lugar. Eso es lo que te permiten hacer las restricciones. Si quieres prevenir que dos espacios de trabajo dependan de diferentes versiones de React, eso es algo que puedes hacer también con restricciones. Así que las restricciones son muy poderosas y te permiten definir en unas pocas líneas de code, a veces incluso tan pequeñas como dos, cómo quieres que se vean tus espacios de trabajo. Y lo bueno es que simplemente funciona, puede simplemente corregir automáticamente todos los problemas, así que si le dices cuál debería ser el estado, simplemente aplicará los cambios a todos tus espacios de trabajo en una línea de comandos.

Otro es que TypeScript puede, sí, así que Yarn puede auto instalar los paquetes de tipos add según sea necesario. Siempre es un poco molesto para mí cuando estoy haciendo algún desarrollo con TypeScript y estoy añadiendo una dependencia y luego veo que en mi editor no aparecen, los tipos no aparecen. Con Yarn, podemos simplemente comprobar si el paquete tiene tipos y si no los tiene, comprobamos si tiene paquetes de tipos definitivamente y luego los instalamos automáticamente. Este comportamiento puede ser desactivado. En la 3.0 es optativo. En la 4.0, creo que lo estamos haciendo opt out, pero es algo que puedes desactivar si eso no es algo que quieres. En términos de community servicio, así que el código abierto es acerca de community. Estamos escribiendo esta herramienta y la estamos poniendo a tu disposición para que la puedas usar para que otros proyectos puedan usarla con el fin de mantener sus propias arquitecturas y eso significa que estamos tratando de ser buenos ciudadanos y estamos tratando de trabajar con la community en la implementación de características o asegurándonos de que los proyectos pueden beneficiarse de los cambios que hacemos, este tipo de cosas. Enumeré algunas de ellas.

La primera es que realmente contribuimos a terceros para corregir dependencias. Mencioné anteriormente este problema sobre las dependencias cuando empiezas a depender de ellas sin declararlas en tu packet.JSON. Aunque puede funcionar en algunos casos, generalmente conduce a problemas muy sutiles donde las versiones no coinciden, lo que significa que a medida que tienes paquetes no eliminados, puedes de repente encontrarte en un estado en el que tu aplicación no funciona incluso si no tocaste ninguna dependencia relacionada con tu proyecto. Para solucionar eso, la solución adecuada es alquilar dependencias pero la mayoría de los gestores de paquetes no muestran realmente esta información muy bien. Con Yarn, intentamos hacerlo. Y cada vez que notamos algo que no parece del todo correcto, intentamos trabajar con los mantenedores para corregir esos problemas. Es importante no solo para Yarn o para sus usuarios, sino también para los usuarios de NPM y PMPM. Como mencioné, esos problemas ocurren en todas partes. Cada vez que tienes algo donde la versión no es del todo compatible, aunque probablemente debería serlo, eso es un problema de

Por ejemplo, es posible que conozcas DESP, que está simulando tus modelos. Eso pasa por los cargadores. Entonces, los cargadores son muy nuevos. No existían para command.js. Empezaron a aparecer para ESM. Somos parte de la discusión para averiguar cómo hacer que sean lo suficientemente potentes para ser prácticos en nuestro mundo.

Realizamos pruebas de extremo a extremo contra muchos proyectos de código abierto. Algo que notamos al contribuir a terceros es que es fácil para ellos agregar accidentalmente otra dependencia, olvidarse de listarla y luego las cosas empiezan a fallar. Para prevenir eso, en nuestro lado, dentro de Yarn mismo, cada tres horas, ejecutamos un montón de pruebas de extremo a extremo instalando la última versión de todos los principales proyectos de código abierto como Zvelt, Gatsby, Webpack, todo tipo de proyectos, realmente, y comprobando si funcionan en pruebas simples. Si no lo hacen, entonces podemos ir inmediatamente a los mantenedores y hablar con ellos y ver cuál sería la mejor solución. Así que ha sido bastante útil tanto para nosotros como para los mantenedores para rastrear las regresiones.

Y finalmente, abogamos por un Corepack no implementado, una nueva herramienta de Node.js que te permite administrar la versión de tu administrador de paquetes en una base por proyecto en lugar de una base global. Eso es algo que me ha parecido muy importante, porque cuando lo piensas, el trabajo de tu administrador de paquetes es bloquear tus dependencias. A partir de ahí, parece un poco extraño que el administrador de paquetes sea la única dependencia de tu proyecto que no estaría bloqueada, ¿verdad? Así que con Corepack, puedes bloquear la versión del administrador de paquetes a una versión específica para que estés completamente seguro de que todos en tu equipo tendrán el mismo comportamiento.

Una cosa a tener en cuenta sobre Corepack es que funciona para Yarn, por lo que se distribuye con Node, y cuando ejecutas Corepack enable, tienes Yarn dentro de tu carpeta bin, pero también funciona para PMPM. Así que eso es algo que también me pareció muy importante, que las cosas deberían funcionar no solo para Yarn, porque somos uno de los otros administradores de paquetes, sino también para PMPM, que es otro. Deberíamos reconocerlos y aceptarlos dentro de la comunidad.

Y eso me lleva a mi otro punto, que es la polinización entre proyectos. Queremos que Yarn sea una especie de plataforma que se pueda utilizar para construir tu propio administrador de paquetes si quieres. Mantenemos una base de datos de dependencias Gauss. Todas esas dependencias problemáticas que mencioné, donde si te falta una, puedes tener comportamientos diferentes de una celda a otra. Eso es algo que rastreamos y que almacenamos dentro de una pequeña base de datos. Y PMPM, por ejemplo, aprovecha esta base de datos para solucionar problemas a medida que se informan. Básicamente, es como una base de datos de compatibilidad. PMPM mismo aprovecha nuestro código para generar normales, no los normales de symlink, sino el archivo concreto que puedes...

Por ejemplo, clip-and-yarn es el framework que usamos para construir nuestro CLI. Y en lugar de mantenerlo dentro del code de yarn y simplemente dejarlo vivir así, lo extraímos dentro de un paquete que puedes usar en tu propia aplicación. Así que incluso si lo que estás haciendo no tiene ninguna relación con los administradores de paquetes, todavía puedes usar code que está escrito para yarn. Eso es un montón de cosas. Y estoy seguro de que no conocías al menos una de ellas.

Lo que pasa con yarn y los administradores de paquetes paralelos en general es que son campos de diamantes. Hay muchas cosas muy diferentes que estamos haciendo, y a veces es difícil ser consciente de que existen antes de que las necesites. Así que al principio, estás como, sí, pero ¿cuál es la diferencia entre A y B? Y luego intentas profundizar, y empiezas a ver que hay características muy pequeñas que están haciendo un todo.

Bueno, hablé de lo que hace yarn, pero ¿dónde no es suficientemente bueno yarn? E indirectamente, ¿qué estamos haciendo para la forma de yarn? En términos de fricción, no estamos exactamente en la etapa en la que me gustaría que estuviéramos. Como mencioné, no importa cuán bueno sea el buffet si no puedes encontrar la puerta del restaurante, ¿verdad? Así que eso es algo que queremos abordar. Queremos ayudarte a encontrar la puerta.

Entonces, para eso, estamos apostando todo a CorePack. CorePack se convertirá en la forma recomendada para instalar un nodo para instalar yarn, y eso lo acerca a ser parte de Node.js. Así que todavía es experimental en Node en sí, pero en lo que respecta a yarn, esa es la herramienta que vamos a recomendar a la gente que use para instalar yarn. Significa que aunque con yarn 2 y 3, se recomendaba hacer check in del binario construido de yarn dentro de tu repositorio, ya no es cierto a partir de yarn 4. El CLI vendrá con batería incluida. Uno de los cambios que hicimos cuando pasamos de 1 a 2 es que yarn obtuvo muchas características nuevas, algunas un poco experimentales, que no incluimos en el binario por defecto, lo que te requiere instalar y gestionar plugins que fueron escritos por nosotros. Eso es algo que estamos cambiando en yarn 4. Estamos graduando todas las características que antes eran plugins para que cuando obtengas el binario de yarn, contenga todas las características en las que hemos estado trabajando, así que la instalación automática de tipos, restricciones, herramientas de espacio de trabajo como por ejemplo yarn workspaces forage, que te permite ejecutar un script en todos tus espacios de trabajo. Esas son cosas que sabemos serán parte de la distribución por defecto de yarn. Otra es que optamos por la caché local. Yarn tiene dos cachés, una es global para la máquina, otra es local, y con la nueva versión, la estamos haciendo optativa para que haya menos archivos que se generan cuando estás ejecutando una instalación.

Seguridad. Eso es algo que debería ser por defecto, no algo en lo que optes. Para hacer eso, tenemos la comprobación de resolución y la actualización del archivo de registro. Esos dos flags previenen completamente cualquier ataque que se haga modificando los metadatos en tu archivo de registro. Puede que hayas oído hablar de los ataques de la cadena de suministro. Eso es algo que no es posible con esos flags. Sin embargo, esos son flags. Necesitas habilitarlos, lo que me lleva a mi otro punto, que es el Modo Ardiente. Yarn intentará detectar en qué modo se está ejecutando. Si detecta que es un entorno inseguro, por ejemplo, una solicitud de extracción pública, por defecto, hará diferentes compromisos entre velocidad y seguridad y, por ejemplo, habilitará los dos flags que mencioné para que no tengas que pensar en seguridad al usar Yarn. Resolución estable. Esa es una estrategia de resolución alternativa en la que estamos trabajando que se utiliza en otros lenguajes, por ejemplo, Go, que protege contra ataques como UA PartialGIS o FakeGIS. Lo que pasa con la mayoría de los ataques en JavaScript es que son extremadamente virales. Una vez que un paquete llega al registro, puede ser recogido por cualquier cosa que dependa de este paquete pero también todas las cosas transitivas que dependen accidentalmente del paquete vulnerable. Con la resolución estable, eliminamos el factor viral. No está del todo listo.

Todavía está en fase experimental. Rompe algunos paquetes antiguos, por ejemplo. Bajo este modo, cosas como Gulp ya no funcionan. Todavía estamos discutiendo con la community para averiguar la mejor manera de implementar esto si realmente queremos hacerlo.

Finalmente, la documentation. Como mencioné, hay muchas cosas por descubrir en Yarn. A menudo tienes muy poco ancho de banda para verlas. Estamos reconstruyendo nuestros sitios web para ser más claros, para presentar mejor toda la información y para tener un mejor contenido en general.

Sólo mencioné estos tres temas principales, pero hay muchas cosas que también estamos mejorando en Yarn, como el protocolo de parche y un tiempo de arranque más rápido. Estamos mejorando las APIs públicas que puedes usar al escribir plugins de Yarn añadiendo nuevos hooks y nuevas funciones. Estamos intentando hacer que Yarn tenga una mejor integración con Git en comandos de virus, para que sepa cómo manipular Git de la mejor manera. Hay muchas cosas que cambian, pero esta es una charla de 20 minutos, así que sólo puedo repasar algunas de ellas. Espero que disfrutes de esta charla. Si tienes alguna pregunta, no dudes en hacerlas en Slido o en contactarme en el pasillo. Me encanta hablar de Yarn. Gracias por tenerme aquí. Muchas gracias. Muchas gracias, Myle. Muy buena masterclass. Aprendí mucho sobre Yarn. Definitivamente lo probaré.

No creo que tengamos algunas preguntas relevantes en Slido hasta ahora, así que gente, despierten, usen esta herramienta para enviar preguntas. Eso no significa que dejaré a Myle ir sin un par de preguntas. La primera de mi parte. Yarn es de código abierto. Cambiemos de lugar, organicemos esto, pregúntanos. Tu advice, cómo empezar a contribuir a Yarn. ¿Hay algunos problemas que son fáciles de solucionar? Tenemos una etiqueta con buenos primeros problemas. Estamos abiertos a que nuevas personas se unan a nosotros en el discord. Unas cuantas veces alguien dijo, ¿sería posible si yo estuviera haciendo esta solución? ¿Sería fusionado? Les damos ideas de cómo hacerlo en línea con el tipo de contribución. Hemos escrito una guía para las pautas de contribución guidelines. Así que, sí, realmente damos la bienvenida a cualquiera para que realmente nos ayude a trabajar en Yarn. Eso es increíble.

Creo que podemos tomar una pregunta o tal vez dos de la sala. ¿Alguna pregunta sobre Yarn? ¿Sí? Déjame correr hacia ti. Acércate. Gracias. Gracias. Acabas de mostrar muchas cosas increíbles que hiciste con Yarn. Y recientemente intenté usar realmente Yarn tree para mejorar nuestro principalmente CI performance y también, por supuesto, obtener todos los beneficios locales de ello. Y revisé la opción de plug and play. No sé si lo mencionaste hoy. Pero la pregunta es cómo una gran organización de cientos de desarrolladores puede simplemente cambiar a esta porque hay problemas con al menos los IDs y, ya sabes. Así es como lo hicimos en mi empresa. Estamos usando plug and play. Y la forma en que hacemos esto es que tienes varios campos herramientas dentro de Yarn mismo para arreglar dependencias. Por ejemplo, en tu configuración de Yarn puedes tener un paquete campo que te permite declarar todas las dependencias que están faltando para que Yarn sepa que están aquí. Y deja de decirte que hay un problema allí. Como mencioné, también tenemos esta database de problemas de compatibilidad que solucionamos automáticamente cuando somos conscientes de ellos. Así que de vez en cuando la gente viene al repositorio y hace un PR solo para agregar nuevas entradas en esta database para que todas las dependencias que adoptan PNP no se vean afectadas por esos problemas.

¿Se recomendaría cambiar de NPM a Yarn en un proyecto grande y de larga duración? Realmente depende de cuáles sean tus prioridades, como mencioné. Así que no puedo ‑‑ No uso NPM. Así que no conozco exactamente todas las ventajas que tiene sobre Yarn. Sé que Yarn funciona para mí. No sé si funcionaría para ti. Claramente estamos tratando de ser quizás un poco más difíciles de trabajar en el sentido de que tenemos más fricción en este momento, como mencioné. Pero al mismo tiempo, estamos tratando de hacer más para detectar problemas antes de que empiecen a aparecer repentinamente en medio de una ejecución de CI y luego tienes que detener lo que estás haciendo para tratar de solucionar las cosas. Así que todo es cuestión de compensaciones. Ve si las cosas funcionan para ti, si quisieras ver algo especial arreglado. Ve si Yarn los soluciona y haz tu elección. Justo. Y así comenzaste tu presentación con muchas afirmaciones sobre el rendimiento. Terminemos con la misma nota y las preguntas exactamente sobre eso. ¿Cuál es tu opinión sobre el resultado no determinista del rendimiento de los gestores de paquetes? ¿Se volverá Yarn más consistente en diferentes máquinas? En general, creo que somos bastante consistentes. La diferencia de tiempo que mencioné entre C.I. y los portátiles todavía era muy lenta. Así que era más como dos líneas yendo de una a otra con PNPM. Cuando estás usando PNP es aún más rápido porque entonces solo estamos escribiendo un solo archivo en el disco, por lo que el paso de enlace básicamente ya no existe. Así que, dependiendo de tus configuraciones, puede ser extremadamente rápido. Increíble, increíble.

Gente, estoy seguro de que tienen más preguntas, más preguntas sobre yarn y tienen la oportunidad de continuar esta discusión porque amablemente pediré a los organizadores que guíen a Myle al área especial donde pueden sentarse y charlar más. Muchas gracias, Myle. Gran presentación. Aplausos Music