Yarn 4 - Gestión Moderna de Paquetes

Rate this content
Bookmark

Yarn 4 es la próxima versión principal de tu gestor de paquetes JavaScript favorito, con un enfoque en rendimiento, seguridad y experiencia de desarrollo. A lo largo de esta charla repasaremos sus nuevas características, cambios importantes y compartiremos nuestros planes a largo plazo para el proyecto.

Si solo has oído hablar de Yarn sin probarlo aún, si no estás seguro de por qué la gente se preocupa tanto por los gestores de paquetes, si te preguntas cómo tu gestor de paquetes puede hacer tu trabajo más simple y seguro, ¡esta es la charla perfecta para ti!

28 min
16 Jun, 2022

Video Summary and Transcription

Yarn es un gestor de paquetes que se enfoca en estabilidad, rendimiento y seguridad. Ofrece características únicas como instalación plug and play, soporte para no módulos y el protocolo exec. Yarn se compromete a ser un buen ciudadano en la comunidad de código abierto y contribuye a solucionar dependencias. Forma parte del grupo de trabajo del cargador de Node.js y aboga por Corepack. Yarn todavía es experimental pero está mejorando su experiencia de usuario y características de seguridad. Se aceptan contribuciones y cambiar a Yarn puede mejorar el rendimiento en proyectos grandes.

Available in English

1. Introducción a Yarn

Short description:

¡Hola a todos! Soy Mael y he estado liderando el desarrollo de Yarn. Hoy hablaré sobre los valores fundamentales de Yarn, nuestros objetivos para cada versión y el futuro de Yarn. Yarn es un gestor de paquetes similar a NPM, que enfatiza la consistencia, estabilidad y buen rendimiento. Lanzamos la primera versión de Yarn hace seis años y ahora estamos trabajando en la versión 4.0.

[♪ música reproduciéndose ♪ ♪ ¡Hola a todos! Mi nombre es Mael. Trabajo en Datadog. Y he estado liderando el desarrollo de Yarn durante los últimos años.

Hoy les hablaré un poco sobre Yarn, cuáles son sus valores fundamentales, qué buscamos en cada versión que lanzamos y les mostraré un vistazo del futuro.

Antes de comenzar, ¿qué es Yarn? Yarn es un gestor de paquetes que probablemente conozcan, similar a NPM, que les permite instalar paquetes en su sistema para resolver dependencias. Y favorece la consistencia y estabilidad, al tiempo que intenta proporcionar buen rendimiento y alta modularidad a sus proyectos.

Ha sido una larga aventura, la primera versión de Yarn se lanzó hace casi seis años, con la versión 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 definir claramente lo que queríamos hacer en el futuro de Yarn, y así llegó la versión 2.0.

En ese momento, hubo muchas discusiones sobre algunos de los aspectos fundamentales en los que hemos estado trabajando en las versiones posteriores a la 3.0, y que seguiremos refinando en la 4.0.

2. Prioridades y características únicas de Yarn

Short description:

¿Por qué otro gestor de paquetes? Yarn aporta propiedades y prioridades únicas. La estabilidad es un principio fundamental, garantizando experiencias consistentes y predecibles. La mantenibilidad y la protección futura son consideraciones clave. Yarn está diseñado para ser modular, permitiendo lógica personalizada y casos de uso específicos. La seguridad también es una prioridad para prevenir futuros ataques. No se discute el rendimiento debido al año actual.

¿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 esto es cierto para los gestores de paquetes, pero también para los empaquetadores, es que aparte de las características y el rendimiento, cada proyecto en el ecosistema de código abierto tiene diferentes propiedades en términos de prioridades, hoja de ruta, modelo de gobierno, mantenibilidad, infraestructura. Todas esas cosas son cosas que debes tener en cuenta cada vez que intentes evaluar un proyecto. 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 se ve a primera vista, pero que tiene sentido cuando intentas invertir en una herramienta a largo plazo.

Así que hablé de prioridades. ¿Cuáles son las prioridades de Yarn? Tenemos cuatro en este momento. La última se agregó recientemente y la discutiremos en las diapositivas futuras, pero primero, la estabilidad es el principio fundamental de Yarn. Queremos que todas tus instalaciones, todas tus experiencias al usar Yarn sean deterministas y predecibles. Si algo funciona para ti, también debería funcionar para tus colegas. Y esta última parte es bastante importante porque asegurarse de que un programa falle 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 ayudarlos 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 siga en buen estado dentro de 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 saludable la base de código? Modernidad es otra. En Yarn 1, notamos que muchos de ustedes tenían casos de uso muy específicos. Era muy difícil para nosotros implementar todas las características que necesitaban, a veces solo una empresa necesitaba. Entonces, en lugar de eso, lo que decidimos hacer con la versión Modern Release de Yarn es hacer que nuestro núcleo sea modular. Lo que significa que puedes escribir complementos, puedes escribir comandos que se integran en la API principal de Yarn que proporcionamos y documentamos. Y puedes crear tu propia lógica en unas pocas líneas de código muy simples. Casi todos los comandos de Yarn se implementan a través de este sistema. Por último, la seguridad. Eso es algo que estamos empezando a introducir, porque aunque Yarn era seguro antes en el sentido de que intentábamos evitar 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. Puedes notar que no hablé sobre el rendimiento. Eso se debe a que estamos en 2022.

3. Características únicas de Yarn

Short description:

Todos los gestores de paquetes tienen un rendimiento similar para las mismas características. Yarn ofrece características únicas como instalación plug and play, soporte para no módulos y el protocolo exec. Yarn también permite la instalación desde git y proporciona el protocolo de parche para aplicar cambios a los paquetes.

Y siendo honestos, 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. Realizamos pruebas de referencia en PMPM, NPM y Yarn. A nivel horario en nuestra infraestructura. Y algo que noté al tratar de ver cuáles eran las diferencias entre los gestores de paquetes es que, aunque PMPM nos añade cierta desventaja en nuestras pruebas automatizadas, eso es algo que no pude reproducir en mi portátil. Creo que esto demuestra que el rendimiento de los gestores de paquetes es muy relativo y en el punto en el que estamos, no cambian muchas cosas.

De todos modos, basta de hablar 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 muy bien. Primero, sobre las instalaciones. Ya que eso es lo principal que hace un gestor de paquetes. No sé si sabes esto, pero incluso las versiones modernas admiten los no módulos muy bien. Puede que recuerdes que en la versión 2.0 lanzamos una nueva estrategia de instalación llamada plug and play que te permite no tener una carpeta de no módulos para compartir tus dependencias en todos los proyectos de tu máquina. Para no tener problemas con dependencias fantasma. Pero también admitimos los no módulos. Si tu objetivo es migrar un proyecto rápidamente, puedes hacerlo. Está muy bien soportado. Tenemos un protocolo llamado exec que te permite crear tus propios paquetes dinámicamente al ejecutar tu propia instalación. El protocolo exec, por ejemplo, supongamos que tienes un paquete que está en SVN. No sé si otras personas están usando SVN, pero a veces nosotros sí. Y si quieres obtener un paquete de allí, entonces tendríamos que implementarlo dentro del gestor de paquetes, es decir, dentro de yarn mismo. Con el protocolo exec, simplemente puedes definir un script en JavaScript que obtenga estos paquetes desde cualquier ubicación que desees. Yo uso SVN, pero podría ser desde cualquier otra ubicación.

Cualquier espacio de trabajo se puede instalar 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 por último, el protocolo de parche es un protocolo que te permite aplicar cambios a cualquier paquete y mantener esos cambios dentro de tu repositorio. Este 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 se ha lanzado. Simplemente puedes usar el protocolo de parche para solucionar lo que sea problemático. Otro caso de uso es, por ejemplo, cuando estás tratando de migrar de CGS a ESM, y hay algo que está fallando en algún lugar, solo una línea que cambiar, pero es difícil enviar un cambio al proyecto principal, puedes usar el paquete de parche para saltar la línea que te está molestando.

4. Características opcionales de Yarn y servicio a la comunidad

Short description:

Yarn tiene características opcionales como la instalación de enlaces simbólicos, un enfoque modular para una implementación fácil, un flujo de trabajo de versiones para gestionar espacios de trabajo cruzados, restricciones para enlazar paquetes y archivos de proyectos, y la instalación automática de paquetes de tipos de TypeScript. Yarn se compromete a ser un buen miembro de la comunidad de código abierto.

Eso fue para las instalaciones. Ahora, Yarn tiene muchas características y algunas de ellas son opcionales. Puedes optar por utilizarlas y empezar a usarlas, pero también puedes simplemente ignorarlas por completo. 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 modelo no concreto en el que cada archivo sea realmente un archivo y cada carpeta sea realmente una carpeta, npm crea enlaces simbólicos que apuntan a un almacén global. Eso es algo que Yarn puede hacer. Lo introdujimos en la versión 3.0 el año pasado y algunas empresas han empezado a utilizarlo y a darnos su opinión.

Lo que realmente me gusta de Yarn es que somos muy modulares, como mencioné antes. Por lo tanto, podemos implementar muchas cosas en muy pocas líneas de código. Cuando implementamos el enlazador de pnpm que te permite hacer esos enlaces simbólicos, en realidad solo necesitamos menos de 100 líneas para hacer la primera iteración. Ese es el tipo de cosa que mencioné cuando dije que queremos que Yarn sea saludable para que dentro de diez años podamos seguir añadiendo características, corrigiendo errores sin estar limitados por las implementaciones anteriores.

Tenemos un flujo de trabajo de versiones que te permite gestionar las versiones de espacios de trabajo cruzados. Por lo tanto, si la única razón por la que estás utilizando, por ejemplo, learner es para gestionar versiones, eso es algo que puedes obtener de forma gratuita simplemente utilizando Yarn. Nosotros utilizamos este flujo de trabajo como parte del desarrollo de Yarn en sí mismo, ya que todos nuestros espacios de trabajo, y tenemos muchos como 30 o algo así, todos nuestros espacios de trabajo están gestionados a través de este sistema. Por lo tanto, lo estamos mejorando con frecuencia. Las restricciones te permiten enlazar 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 cumplan con algunos criterios que tienes, por ejemplo, que ninguno de ellos dependa de alguna dependencia, como, si tienes tanto Lowdash como Underscore, eso sería un problema, por lo que es posible que desees evitar que uno de ellos se agregue en algún lugar. Eso es lo que te permiten hacer las restricciones. Si quieres evitar que dos espacios de trabajo dependan de diferentes versiones de React, eso es algo que también puedes hacer con las restricciones. Las restricciones son muy poderosas y te permiten definir en muy pocas líneas de código, a veces incluso solo dos, cómo quieres que sean tus espacios de trabajo. Y lo bueno es que simplemente funciona, puede solucionar automáticamente todos los problemas, por lo que si le dices cómo debería ser el estado, simplemente aplicará los cambios a todos tus espacios de trabajo en una sola línea de comandos.

Otra característica es que TypeScript puede, sí, Yarn puede instalar automáticamente los paquetes de tipos según sea necesario. Siempre me resulta un poco molesto cuando estoy desarrollando en TypeScript y agrego una dependencia y luego veo que en mi editor no se muestran los tipos. Con Yarn, simplemente podemos comprobar si el paquete tiene tipos y, si no los tiene, comprobamos si tiene paquetes de tipos definidos y luego los instalamos automáticamente. Este comportamiento se puede desactivar. En la versión 3.0 es opcional. En la versión 4.0, creo que lo estamos haciendo por defecto, pero es algo que puedes desactivar si no lo deseas. En cuanto al servicio a la comunidad, el código abierto se trata de la comunidad. Estamos escribiendo esta herramienta y poniéndola a tu disposición para que la puedas utilizar y para que otros proyectos puedan utilizarla con el fin de mantener sus propias arquitecturas y eso significa que estamos tratando de ser buenos miembros de la comunidad y estamos tratando de trabajar con la comunidad en la implementación de características o en asegurarnos de que los proyectos puedan beneficiarse de los cambios que hacemos, ese tipo de cosas. Enumeré algunas de ellas.

5. Contribuyendo a solucionar dependencias

Short description:

Contribuimos con terceros para solucionar dependencias y abordar el problema de los paquetes no eliminados que causan problemas sutiles. Yarn tiene como objetivo mostrar información de dependencias y colaborar con los mantenedores para resolver problemas de compatibilidad. Esto es crucial para los usuarios de Yarn, NPM y PMPM.

El primero es que realmente contribuimos con terceros para solucionar dependencias. Mencioné anteriormente este problema de las dependencias cuando comienzas a depender de ellas sin declararlas en tu archivo packet.JSON. Si bien puede funcionar en algunos casos, generalmente conduce a problemas muy sutiles donde las versiones no coinciden, lo que significa que, como tenías paquetes no eliminados, de repente puedes encontrarte en un estado donde tu aplicación no funciona incluso si no has tocado ninguna dependencia relacionada de tu proyecto. Para resolver eso, la solución adecuada es liberar las dependencias, pero la mayoría de los gestores de paquetes no muestran esta información de manera adecuada. Con Yarn, intentamos hacerlo. Y cada vez que notamos algo que no parece estar del todo bien, intentamos trabajar con los mantenedores para solucionar esos problemas. Esto es importante no solo para Yarn o sus usuarios, sino también para los usuarios de NPM y PMPM. Como mencioné, estos 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

6. Node.js Loaders and Corepack

Short description:

Formamos parte del grupo de trabajo de Node.js Loaders, trabajando en hacer que los loaders sean lo suficientemente potentes como para ser prácticos. Realizamos pruebas de extremo a extremo en proyectos de código abierto para evitar problemas de dependencias. Abogamos por Corepack, una herramienta para gestionar las versiones del gestor de paquetes a nivel de proyecto. Corepack funciona tanto para Yarn como para PMPM. Apuntamos a una polinización entre proyectos y mantenemos una base de datos de compatibilidad para dependencias problemáticas.

Dependencia Gauss. Formamos parte del grupo de trabajo de Node.js Loaders. Los loaders son la forma en que Node.js te permite interceptar la llamada requerida y dirigirla a diferentes ubicaciones. Por ejemplo, podría ser cargar modelos desde HTTP en lugar de cargarlos desde el disco. Podría ser cargar modelos desde archivos compilados en lugar de cargarlos desde archivos individuales. Hay muchos casos de uso para los loaders.

Por ejemplo, puede que conozcas DESP, que simula tus modelos. Eso pasa a través de los loaders. Los loaders son muy nuevos. No existían para command.js. Estaban empezando a aparecer para ESM. Formamos parte de la discusión para descubrir cómo hacer que sean lo suficientemente potentes como para ser prácticos en nuestro mundo.

Realizamos pruebas de extremo a extremo en muchos proyectos de código abierto. Algo que notamos al contribuir con terceros es que es fácil que accidentalmente agreguen otra dependencia, se olviden de listarla y luego las cosas comiencen a fallar. Para evitar eso, en nuestro lado, dentro de Yarn mismo, cada tres horas ejecutamos un conjunto 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 funcionan, podemos ir inmediatamente a los mantenedores y hablar con ellos para ver cuál sería la mejor solución. Ha sido muy útil tanto para nosotros como para los mantenedores para rastrear las regresiones.

Y finalmente, abogamos por Corepack, una nueva herramienta de Node.js que te permite gestionar la versión de tu gestor de paquetes a nivel de proyecto en lugar de a nivel global. Es algo en lo que he sentido un gran interés, porque si lo piensas, el trabajo de tu gestor de paquetes es bloquear tus dependencias. A partir de ahí, parece un poco extraño que el gestor de paquetes sea la única dependencia de tu proyecto que no esté bloqueada, ¿verdad? Con Corepack, puedes bloquear la versión del gestor de paquetes a una versión específica para asegurarte de que todos en tu equipo tengan el mismo comportamiento exacto.

Algo 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 en tu carpeta bin, pero también funciona para PMPM. Es algo en lo que también he sentido un gran interés, que las cosas funcionen no solo para Yarn, porque somos uno de los otros gestores de paquetes, sino también para PMPM, que es otro. Debemos 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 gestor de paquetes si así lo deseas. Mantenemos una base de datos de dependencias Gauss. Todas esas dependencias problemáticas que mencioné, donde si falta una, puedes tener diferentes comportamientos de una celda a otra. Eso es algo que rastreamos y almacenamos en 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 utiliza nuestro código para generar normales, no los normales de enlace simbólico, sino el archivo concreto que puedes...

7. Aprovechando las características de Yarn y el gestor de paquetes

Short description:

Yarn ha implementado una ostra que te permite definir diseños para paquetes. Han extraído código en paquetes que otros gestores pueden utilizar. Yarn también tiene varias bibliotecas, como clip-and-yarn, que se pueden utilizar en cualquier aplicación.

los normales concretos en estilo, como el de NPM. Hemos implementado una ostra, que te permite definir el diseño correcto dado un conjunto de paquetes. Y hemos podido extraer este código dentro de un paquete para que otros gestores de paquetes puedan aprovecharlo para implementar este mismo tipo de comportamiento. Y tenemos un montón de bibliotecas que publicamos por separado.

Por ejemplo, clip-and-yarn es el marco que utilizamos para construir nuestra CLI. Y en lugar de mantenerlo dentro del código de yarn y dejarlo vivir así, lo hemos extraído dentro de un paquete que puedes utilizar en tu propia aplicación. Así que incluso si lo que estás haciendo no tiene ninguna relación con los gestores de paquetes, aún puedes utilizar código que está escrito para yarn. Eso es muchas cosas. Y estoy seguro de que no conocías al menos una de ellas.

La cosa con yarn y los gestores de paquetes paralelos en general es que son campos diamante. Hay muchas cosas muy diferentes que estamos haciendo, y a veces es difícil ser consciente de que existen antes de que los necesites. Así que al principio, estás como, sí, pero ¿cuál es la diferencia entre A y B? Y luego intentas investigar, y empiezas a ver que hay características muy pequeñas que lo hacen todo completo.

8. Mejorando Yarn y las características de seguridad

Short description:

Yarn se centra en abordar la fricción y mejorar la experiencia del usuario. CorePack se está convirtiendo en la herramienta recomendada para instalar Yarn, acercándolo a ser parte de Node.js. Yarn 4 incluye todas las características que antes se ofrecían como complementos, como la instalación automática de tipos, restricciones y herramientas de espacio de trabajo. La caché local ahora es opcional, lo que reduce la cantidad de archivos generados. Las características de seguridad como la comprobación de resolución y la actualización del archivo de registro evitan los ataques a la cadena de suministro. El Modo Ardent de Yarn ajusta automáticamente los compromisos entre velocidad y seguridad. La resolución estable, inspirada en otros lenguajes, mitiga los ataques virales.

De acuerdo, hablé sobre lo que hace Yarn, pero ¿dónde no es lo suficientemente bueno? Y, indirectamente, ¿qué estamos haciendo para mejorar Yarn? En cuanto a la fricción, no estamos exactamente en el punto en el 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? Eso es algo que queremos abordar. Queremos ayudarte a encontrar la puerta.

Para eso, nos estamos enfocando en CorePack. CorePack se convertirá en la forma recomendada de instalar Node.js para instalar Yarn, lo que lo acerca a ser parte de Node.js. Aunque todavía es experimental en Node mismo, en lo que respecta a Yarn, esa es la herramienta que recomendaremos a las personas que utilicen para instalar Yarn. Esto significa que, aunque con Yarn 2 y 3, se recomendaba incluir el binario construido de Yarn en tu repositorio, eso ya no es cierto a partir de Yarn 4. La CLI vendrá con todo incluido. Uno de los cambios que hicimos al pasar de la versión 1 a la 2 es que Yarn obtuvo muchas características nuevas, algunas un poco experimentales, que no incluimos en el binario predeterminado, lo que requería que instalaras y administraras complementos que nosotros escribimos. Eso es algo que estamos cambiando en Yarn 4. Estamos graduando todas las características que antes eran complementos para que, cuando obtengas el binario de Yarn, contenga todas las características en las que hemos estado trabajando, como 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 que deben formar parte de la distribución predeterminada de Yarn. Otra característica es que la caché local es opcional. Yarn tiene dos cachés, una es global para la máquina y otra es local, y con la nueva versión, la estamos haciendo opcional para que se generen menos archivos cuando ejecutes una instalación.

Seguridad. Eso es algo que debería ser predeterminado, no algo en lo que optas. Para hacer eso, tenemos la comprobación de resolución y la actualización del archivo de registro. Estas dos opciones evitan por completo cualquier ataque que se realice modificando los metadatos en tu archivo de registro. Es posible que hayas oído hablar de los ataques a la cadena de suministro. Eso es algo que no es posible con estas opciones. Sin embargo, estas son opciones que debes habilitar, lo que me lleva a otro punto, que es el Modo Ardent. 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 tomará decisiones diferentes entre velocidad y seguridad y, por ejemplo, habilitará las dos opciones que mencioné para que no tengas que preocuparte por la seguridad al usar Yarn. Resolución estable. Esta es una estrategia de resolución alternativa en la que estamos trabajando y que se utiliza en otros lenguajes, como Go, y que protege contra ataques como UA PartialGIS o FakeGIS. La cosa con la mayoría de los ataques en JavaScript es que son extremadamente virales. Una vez que un paquete llega al registro, puede ser utilizado por cualquier cosa que dependa de este paquete, pero también por todas las cosas transitivas que dependen accidentalmente del paquete vulnerable. Con la resolución estable, eliminamos el factor viral. Aún no está completamente listo.

9. Fase experimental de Yarn y documentación

Short description:

Yarn todavía está en fase experimental y rompe algunos paquetes antiguos. Las discusiones con la comunidad están en curso para determinar la mejor forma de implementarlo. La documentación se está reconstruyendo para proporcionar información más clara y un mejor contenido. Otras mejoras incluyen el protocolo de parche, un tiempo de inicio más rápido, APIs públicas mejoradas para escribir complementos de Yarn y una mejor integración con Git. Debido a limitaciones de tiempo, solo se cubrieron algunos temas en esta charla de 20 minutos. No dudes en hacer preguntas en Slido o contactarme. ¡Gracias por tu interés en Yarn!

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 comunidad para determinar la mejor forma de implementar esto si realmente queremos lanzarlo.

Finalmente, la documentación. 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, presentar mejor toda la información y tener un mejor contenido en general.

Solo mencioné esos tres temas principales, pero también estamos mejorando muchas cosas en Yarn, como el protocolo de parche y un tiempo de inicio más rápido. Estamos mejorando las APIs públicas que puedes usar al escribir complementos de Yarn agregando nuevos hooks y nuevas funciones. Estamos tratando de lograr una mejor integración de Yarn 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 solo puedo mencionar algunas de ellas. Espero que disfrutes esta charla. Si tienes alguna pregunta, no dudes en hacerlas en Slido o en contactarme en el pasillo. Me encanta hablar sobre Yarn. Gracias por tenerme aquí. Muchas gracias. Muchas gracias, Myle. Muy buena sesión. Aprendí mucho sobre Yarn. Definitivamente lo probaré.

QnA

Contribuyendo a Yarn y Plug and Play

Short description:

Yarn es de código abierto. ¿Cómo empezar a contribuir? Tenemos problemas etiquetados como 'good first issues' para soluciones sencillas. Únete a nosotros en Discord. Ofrecemos orientación y tenemos pautas de contribución. Damos la bienvenida a cualquier persona que nos ayude con Yarn. Una pregunta de la audiencia fue sobre cambiar a plug and play en una gran organización. Tenemos herramientas en Yarn para solucionar dependencias, como el campo 'package' en la configuración. También tenemos una base de datos de problemas de compatibilidad que solucionamos automáticamente. Es posible cambiar a plug and play.

No creo que tengamos preguntas relevantes en Slido hasta ahora, así que, gente, despierten, usen esta herramienta para enviar preguntas. Eso no significa que dejaré que Myle se vaya sin un par de preguntas. La primera es de mí mismo. Yarn es de código abierto. Cambiemos de lugar, organicemos esto, pregúntanos. ¿Cuál es tu consejo sobre cómo empezar a contribuir a Yarn? ¿Hay problemas fáciles de solucionar? Tenemos una etiqueta con 'good first issues'. Estamos abiertos a que nuevas personas se unan a nosotros en Discord. Algunas veces alguien dijo, ¿sería posible si yo hiciera esta solución? ¿Sería fusionada? Les damos ideas sobre cómo hacerlo acorde al tipo de contribución. Hemos escrito una guía de pautas de contribución. Así que, sí, realmente damos la bienvenida a cualquiera que realmente nos ayude a trabajar en Yarn. Eso es increíble.

Creo que podemos tomar una o tal vez dos preguntas de la sala. ¿Alguna pregunta sobre Yarn? ¿Sí? Déjame acercarme a ti. Acércate. Gracias. Gracias. Acabas de mostrar muchas cosas increíbles que hiciste con Yarn. Y recientemente intenté usar el árbol de dependencias de Yarn para mejorar nuestro principalmente el rendimiento de CI y, 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 con cientos de desarrolladores puede cambiar a esto porque hay problemas con al menos las IDs y, ya sabes. Eso es lo que hicimos en mi empresa. Estamos usando plug and play. Y la forma en que lo hacemos es que tienes varias herramientas dentro de Yarn mismo para solucionar dependencias. Por ejemplo, en la configuración de tu Yarn puedes tener un campo 'package' que te permite declarar todas las dependencias que faltan para que Yarn sepa que están aquí. Y deje de decirte que hay un problema allí. Como mencioné, también tenemos esta database de problemas de compatibilidad que solucionamos automáticamente cuando tenemos conocimiento de ellos. Así que de vez en cuando la gente viene al repositorio y hace un PR solo para agregar nuevas entradas a esta database para que todas las dependencias que adoptan PNP no se vean afectadas por esos problemas.

Switching to Yarn and Performance

Short description:

Cambiar de NPM a Yarn en un proyecto grande depende de las prioridades y los compromisos. Yarn tiene como objetivo mostrar problemas antes de que afecten las ejecuciones de CI. En cuanto al rendimiento, Yarn es bastante consistente y el uso de PNP puede hacerlo aún más rápido. Otras preguntas se pueden discutir en un área especial.

Así que definitivamente es posible. Es un poco de trabajo porque tienes que revisar las dependencias faltantes y agregarlas a esa configuración. Pero en general, está en un estado bastante bueno. Gracias por preguntar. Y sí, tenemos algunas preguntas en realidad. Vamos a leerlas en voz alta.

¿Sería recomendable 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 sé 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 este momento, como mencioné. Pero al mismo tiempo, estamos tratando de hacer más para mostrar problemas antes de que comiencen a aparecer de repente en medio de una ejecución de CI y luego tener que detener lo que estás haciendo para tratar de solucionar las cosas. Así que todo es una cuestión de compromiso. Ver si las cosas funcionan para ti, si quieres ver una cosa especial solucionada. Ver si Yarn las soluciona y hacer tu elección. Bastante justo. Y así comenzaste tu presentación con muchas afirmaciones sobre el rendimiento. Terminemos en la misma nota y las preguntas son exactamente sobre eso. ¿Cuál es tu opinión sobre el resultado de rendimiento no determinista de los gestores de paquetes? ¿Yarn se volverá más consistente en diferentes máquinas? En general, creo que somos bastante consistentes. La diferencia de tiempo que mencioné entre C.I. y las laptops todavía era muy lenta. Así que fue más solo dos líneas pasando de una a la otra con PNPM. Cuando usas PNP es aún más rápido porque luego solo estamos escribiendo un solo archivo en el disco, por lo que el paso de enlace básicamente ya no existe. Entonces, dependiendo de tu configuración, puede ser extremadamente rápido. Increíble, increíble.

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

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
WorkshopFree
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.