Elevando Monorepos con los Espacios de Trabajo de npm

Hola, y bienvenidos a la masterclass de monorepos con los espacios de trabajo de NPM. Permíteme empezar presentándome. Mi nombre es Rui Aduno. Soy un desarrollador de software en el equipo de NPM CLI en GitHub. He estado trabajando en NPM CLI durante casi tres años. Trabajé en la reescritura de NPM v7 y en muchas de las características de las que vamos a hablar aquí hoy, especialmente en los espacios de trabajo. Estoy muy emocionado de compartir parte de ese trabajo con ustedes hoy.

Comencemos con una visión general de lo que vamos a cubrir aquí hoy. Empezaremos con una introducción a lo que son los espacios de trabajo de NPM y luego cubriremos algunos ejemplos muy prácticos tratando de acercarnos lo más posible al uso real y también señalaremos algunas de las cosas que deberías esperar. Así que, comencemos.

Los espacios de trabajo de NPM. ¿Qué es? Así que, comencemos con los espacios de trabajo, que es básicamente este concepto introducido por Yarn hace un tiempo y básicamente es una forma de ayudarte a gestionar muchos paquetes dentro de un solo repositorio y para NPM, los espacios de trabajo de NPM es el nombre amplio que dimos al conjunto de características que te ayudan a lograr eso, básicamente te ayudan a gestionar múltiples paquetes anidados dentro de un paquete de nivel superior. Así que, te va a ayudar a centralizar la instalación de todas las dependencias en una sola carpeta de módulos de node. Así que, también terminarás teniendo solo un archivo de bloqueo de paquetes, y hay algunas ventajas en eso, definitivamente es la forma ideal de gestionar monorepos, y gracias a eso puedes tener un solo lugar para gestionar todos tus problemas, y básicamente gestionar tu proyecto y tu comunidad. Pero también, en el lado técnico, también puedes centralizar, tener un solo lugar para ejecutar todas tus tareas, construir, cualquier cosa que puedas imaginar, necesitas todo junto para hacer funcionar tu proyecto con todos los paquetes, puedes tenerlo todo en un solo lugar. Así que, podría ayudar mucho dependiendo del estilo del proyecto que estás tratando de lograr. Otra cosa que me gustaría señalar aquí es la línea de tiempo, solo para dar un poco de esta noción de cómo hemos estado mejorando iterativamente los espacios de trabajo de NPM. Y puedes ver que todo comenzó en agosto de 2020 con el lanzamiento de la versión 7.0 de NPM CLI que introdujo por primera vez el soporte para instalar NPM, los espacios de trabajo. Y luego en la versión 7.7, otra gran actualización, que introdujo por primera vez las propiedades de configuración de un espacio de trabajo o dirigidas a todos los espacios de trabajo y el primer comando que los soportó con NPM Run y NPM Exec. Hubo muchas más, pero solo quería ilustrar cómo hemos estado mejorando. Y definitivamente puedes esperar ver más mejoras en los Espacios de Trabajo de NPM.

Así que comencemos con algunos ejemplos aquí. Tengo este proyecto que tengo en el lado izquierdo aquí, que es una aplicación simple que he armado tratando de acercarme lo más posible a un proyecto de la vida real. Esta es una especie de aplicación web que consta de dos servicios diferentes. Así que puedes ver que tengo mi servicio de user sense, mi servicio de web app, e incluso configuré un tercer espacio de trabajo aquí, que son las diapositivas que estás viendo ahora mismo. Así que todos forman parte de esta aplicación monorepo que estoy gestionando aquí.

Y con eso espero poner algunos ejemplos que están muy cerca de cómo usarías esto en tu vida real. Así que puedes ver que todos tienen un montón de dependencias aquí usando NextJS, los servicios usando Fastify. Así que puedo empezar rápidamente ejecutando NPM Ls aquí, y podemos ver cómo Ls es un comando que es consciente de los espacios de trabajo, y va a resaltar cada uno de los espacios de trabajo en mi proyecto, e incluso listar las dependencias de cada espacio de trabajo cuando ejecuto NPM Ls. Así que es el primer comando que sabe que tiene soporte de primera clase para espacios de trabajo. Así que avanzando aquí, me gustaría destacar NPM Init. Probablemente es la mejor manera de empezar tu espacio de trabajo, porque se va a asegurar que cada paso que se necesita va a terminar estando allí. Así que básicamente, todo lo que necesitas para rastrear un paquete anidado como un espacio de trabajo es asegurarte de que tienes la carpeta con un archivo package.json dentro de ella, dentro de tu proyecto, y luego simplemente añadir ese nombre de carpeta a tu campo de espacios de trabajo de tu package.json en el nivel superior. Así que usar NPM init va a asegurar que esos requisitos están allí. Así que voy a ejecutar un ejemplo rápido aquí en mi aplicación de muestra. Voy a crear un nuevo espacio de trabajo. Digamos que lo voy a llamar el sitio web. Así que puedo ejecutar NPM init. Estoy usando dash y aquí para aceptar todos los valores por defecto. Y estoy apuntando a un sitio web. Así que eso va a crear una carpeta de sitio web con un archivo package.json dentro de ella. Va a imprimir el contenido del archivo package.json aquí. Y como mencioné antes, el otro punto realmente importante que NPM init se encarga de es colocar la referencia al sitio web dentro de mi archivo package.json en mi carpeta de nivel superior. Así que con eso, todo está configurado. Si instalo npm aquí, ahora el árbol de instalación va a estar rastreando el sitio web. Y si ejecuto npm ls de nuevo, voy a ver el sitio web listado como uno de los espacios de trabajo aquí resaltado en verde. Así que definitivamente es la forma recomendada de empezar con un nuevo espacio de trabajo dentro de tu proyecto.

Y podemos pasar a otro aspecto muy importante. ¿Cómo añades dependencias a uno de tus espacios de trabajo? Así que un ejemplo rápido aquí de nuevo. Voy a cambiar la configuración del espacio de trabajo aquí, para que puedas ver que puedes ir prácticamente a cualquier parte. Así que puedo declarar un espacio de trabajo npm, voy a apuntar al sitio web que acabo de crear.

Y supongamos que quiero instalar un paquete, voy a instalar este paquete Simple Slider en mi sitio web. Así que puedo ejecutar ese comando, lo que va a hacer es instalar el nombre del paquete Simple Slider desde el registro. Lo va a poner como una dependencia de mi masterclass de sitio web. Así que puedo buscar su package JSON y puedo ver que el Simple Slider está declarado aquí como una dependencia. Pero si busco la carpeta nodemodules dentro del nivel superior de mi monorepo app, puedo ver que Simple Slider fue puesto allí.

Así que eso es básicamente uno de los conceptos más importantes con los espacios de trabajo de NPM, es que todo intenta ser elevado tanto como sea posible, sólo evita esa elevación o ese traer un nivel arriba cada dependencia, si encuentra duplicaciones. Así que si hay duplicaciones, entonces podrías terminar con una carpeta de nodos modules dentro de tu masterclass que deduplica esos paquetes para que pueda funcionar como se espera.

Así que todo eso para mencionar, una cosa que he visto como una repetición común con los espacios de trabajo es que algunas personas solían tener esta opción de configuración de no elevación. Esa era una opción que Yarn introdujo para básicamente tener espacios de trabajo que digan, vale, necesito esta dependencia, pero necesito asegurarme de que está dentro de una carpeta de nodos modules dentro de mi masterclass. Así que debido a la naturaleza de algún módulo, algún paquete, realmente necesitan confiar en el hecho de que están en esa posición en el sistema de archivos. Así que eso es algo que Yarn inventó para básicamente dar una escotilla de escape a los usuarios para tener un poco más de control sobre dónde se colocan sus dependencias. Así que para los espacios de trabajo de NPM, actualmente estamos siguiendo eso como una nueva característica. Lo estamos discutiendo en nuestros procesos de RFC. Estamos deseando proporcionar a los usuarios una forma de hacerlo. Aún no estamos seguros de si va a ser usando ese mismo valor de configuración de no-elevación o va a ser algo diferente. Pero mientras tanto, quería básicamente proporcionar una forma de desbloquearte si alguna vez te encuentras con ese escenario. En mi aplicación de muestra aquí, en realidad lo golpeé. Estoy usando este cliente Prisma, que es esta biblioteca para manejar. Básicamente es un ORM para bases de datos y lo estoy usando en ambos servicios aquí de esta aplicación de muestra. Cuando se elevó a la cima de mi aplicación, básicamente no funcionó. Así que una forma rápida de desbloquearme y hacer que funcione es duplicarlo y tenerlo en ambas carpetas de mis servicios dentro de sus nodos modules. Una forma rápida de lograr esa duplicación fue básicamente que puse algunos paquetes simulados aquí que básicamente entrarían en conflicto con el espacio de nombres del paquete que están usando. Así que usé Prisma y Prisma Client y los declaré usando NPM-liasis y apuntando a simplemente algo más. En mi caso aquí, estoy usando este módulo Abraa, pero realmente podría ser cualquier cosa. Esto es para asegurarme de que cuando declaro en mi servicio de sincronización de usuarios aquí, lo tengo dentro de mi package.json. Simplemente tengo la declaración correcta de las versiones esperadas que tengo para estas bibliotecas para que cuando NPM lo instale, realmente va a poner las carpetas del Cliente Prisma dentro de mis nodos de sincronización de usuarios modules. Así que es básicamente una forma de forzar ese mismo comportamiento de no desperdicio, y podría ayudar a desbloquear a otros usuarios allí. Así que es una forma muy práctica de ponerse en marcha hoy. Pero definitivamente mantén un ojo porque definitivamente hay cosas en marcha. Podría mejorar muy pronto en el soporte predeterminado de NPM CLI.

Así que avanzando, también quería cubrir la ejecución de scripts. Y aquí, también coloco algunos ejemplos de cómo puedes ejecutarlo. Puedes ejecutarlo utilizando el nombre del espacio de trabajo. También un ejemplo, si tu espacio de trabajo tiene un alcance, entonces también tienes que definir el alcance. Pero también puedes llamarlo utilizando el nombre de la ruta del espacio de trabajo. Y básicamente aquí, en mi proyecto, puedo mostrar rápidamente si apunto a ese usuario servicio de sincronización de espacio de trabajo que tengo, y ejecuto sus pruebas, puedes ver que va a ejecutar las pruebas para ese espacio de trabajo. Y es básicamente lo mismo que navegar a esa carpeta de espacio de trabajo y ejecutar NPM pruebas dentro de ella.

Sí, y quiero avanzar aquí a ejemplos un poco más complejos que he reunido, básicamente mostrando cómo en un monorepo más complejo puedes orquestar tus scripts de una manera que pueden ser mucho más útiles. Así que empezando rápidamente aquí, siguiendo el ejemplo de prueba que acabo de dar, este es el, este es un ejemplo, estos son los scripts de mi paquete de nivel superior, JSON. Y estoy declarando esta prueba Columna web app y prueba Columna user sync nombrada después de cada uno de mis espacios de trabajo. Y básicamente están llamando a las pruebas y apuntando a cada uno de los espacios de trabajo allí. De esta manera tengo estos múltiples scripts en mi comando de nivel superior y voy a estar usando, voy a estar usando este archivo binario run dash s que, en realidad viene de este paquete de línea de usuario llamado npm run all. Así que lo anoté aquí. Es un paquete muy útil, te ayuda a ejecutar múltiples scripts y te da mucho más flexibilidad en la forma en que lo haces. Así que básicamente aquí le estoy diciendo a run s que ejecute todos mis objetivos de prueba columna definidos aquí en mi archivo. Así que volvamos a mi carpeta raíz aquí y ejecutemos npm test y veamos qué pasa. Así que puedes ver que ejecuta el objetivo de prueba de la aplicación web primero, que está ejecutando la prueba dentro de ese espacio de trabajo. Y luego de eso, ejecutó la prueba de sincronización de usuarios, que ejecutó la prueba para ese espacio de trabajo de sincronización de usuarios, y puedes ver que tuvo éxito.

Así que un poco más evolucionado, pero siguiendo este primer ejemplo. También vamos a ejecutar mis servidores DAB web aquí. Así que tengo algo similar, esa llamada en la aplicación web y la sincronización de usuarios, y estoy apuntando npm run a mis espacios de trabajo, y estoy ejecutando el script DAB de cada uno de ellos. Pero la particularidad de los servidores es que necesito que todos ellos estén funcionando al mismo tiempo, ¿verdad? Así que esto es también algo proporcionado por npm run all, que voy a estar usando para ejecutar, usando run-p, que va a estar ejecutando ambos de estos objetivos en paralelo. Va a empezar todos al mismo tiempo, mantenerlos en funcionamiento, para que pueda tener todo funcionando y realmente usar mi servidor de desarrollo, navegar a mi UI. Probémoslo rápidamente aquí. Voy a ejecutar npm run dev. Puedes ver que va a ejecutar todos los scripts y sus dependencias. Así que voy a avanzar aquí. Esta siguiente línea está apuntando al servidor que se está ejecutando en mi host local. Así que ahora, una vez que todo se inicia, puedo ver que mi lista de usuarios está de nuevo en marcha. Puedo ver algunos usuarios.

Puedo hacer clic alrededor, navegar, y puedo ver que mi aplicación web está funcionando como se esperaba. Así que aquí quiero destacar este nuevo comando. Algo nuevo. Lo introdujimos a finales del año pasado en la versión 7.20. Es un comando para ayudarte a establecer y recuperar claves, valores de tu paquete. No sólo es útil en el contexto de las masterclass, sino que es súper útil cuando se utiliza en el contexto de las masterclass. Así que puede ser utilizado para, déjame destacar aquí rápidamente. Si ejecutas como npm pkg get, puede ser simplemente un paquete simple. Va a imprimir básicamente el contenido de package.json y también puedes filtrar por propiedades, digamos nombre, y entonces obtengo el nombre de mi paquete allí. Así que cuando realmente traes el soporte a las propiedades de las masterclass, puede realmente volverse muy poderoso, como en este ejemplo aquí, voy a recuperar el nombre de la versión de todas mis masterclass. Así que esta opción de configuración aquí, //tapus, es básicamente una forma de decir, vale, apunta a todas mis masterclass configuradas. Así que si ejecuto eso, puedes ver que devolvió el nombre de la versión de cada una de mis masterclass e incluso están clasificadas por el nombre de la masterclass. Así que puede ser realmente útil. Y también para destacar un poco más de cómo pueden ser útiles, déjame también establecer algunos data en estos archivos package.json. Digamos que estoy gestionando este proyecto y es un proyecto de código abierto. Sólo quiero mostrar información sobre cómo los usuarios pueden encontrar mi trabajo. Así que puedo seguir adelante y usar npm pkg set. Digamos que voy a establecer una clave siguiente a todos estos package.jsons y voy a apuntarlo a mi URL de patrocinadores de GitHub, y voy a apuntar a todas las masterclass configuradas. Así que puedo ejecutar eso y si miras, digamos, mi usuario está diciendo package.json, puedes ver que la información de fundación está allí, lo mismo ocurre con mi package.json de la aplicación web. Así que puede ser una parte increíble de la forma de ayudarte a gestionar todos esos data en tu package.json a través de todas las masterclass configuradas. También destaca aquí que NPM version, NPM publish también tienen soporte para masterclass. Así que si quieres cortar, digamos, una nueva versión de parche de una masterclass, eso es posible hoy. Y algo a tener en cuenta es, como puedes ver aquí, he aumentado mi versión a v1.0.1. Puedo mirar mi package JSON allí y ver que la versión está allí. Pero una cosa a tener en cuenta que es un poco diferente ahora de la forma en que NPM version funciona por defecto es que no hay mucho compromiso y etiquetado cuando se ejecuta NPM version. Así que algo a tener en cuenta, pero definitivamente puedes esperar mejoras a NPM version específicamente. Así que para terminar todo lo que quería ejecutar un ejemplo rápido aquí. Estoy usando NPM exec. Es básicamente NPX. Se promovió a un subcomando en NPM CLI desde la versión 7.

Y quería crear rápidamente otra masterclass. Llamémosla imprimir el directorio de trabajo actual. Y voy a usar exec para ejecutar básicamente esta masterclass como un comando en todas las demás masterclass que tengo configuradas, simplemente uniendo todo usando todos los comandos que acabamos de ver. Así que permíteme saltar rápidamente a esa carpeta e iniciar un archivo index.js. Y esto básicamente imprimirá el directorio de trabajo actual. Esto será útil porque quiero destacar la naturaleza de cómo npm exec o npm run. Se ejecutan en el contexto de cada carpeta. Quiero imprimir el directorio de trabajo actual solo para asegurarme de eso. Así que a continuación, voy a npm pkg set un valor bin de index.js a esa recién creada masterclass printcwd para que rastree correctamente ese archivo binario, index.js. Ahora voy a npm install para juntar todo, asegurarme de que mi bin esté correctamente vinculado a mi carpeta de modules de node. Ahora puedo npm exec, y voy a llamar a mi módulo y le diré que se ejecute dentro de cada una de las masterclass. Y puedes ver que obtuve el resultado esperado aquí. Básicamente imprimió la ruta para cada una de mis masterclass cuando se ejecutó dentro de ellas. Así que solo un ejemplo rápido aquí para cerrar, resumir y juntar todo, cómo puedes usar todos estos comandos. Así que si quieres aprender más sobre esto, definitivamente consulta los docs oficiales. Tenemos una sección exclusiva sobre las masterclass, pero también hay documentation en cada uno de estos comandos explicando un poco más cómo usarlos. Y si quieres encontrarme, estamos en Twitter, GitHub, y aquí también está mi sitio web. Así que realmente espero que esto haya sido útil y muy buenos ejemplos de la vida real, y espero que lo disfrutes. Gracias. Fue una sesión de demostración estupenda. Así que... Gracias. Vale. Así que hiciste la pregunta, ¿qué fue y presentó un soporte para NPM masterclass y el 65% dice que es 7.0. Y- Sí. ¿Cuál era la correcta? Bueno, sí, fue durante el 7.0, pero creo que di la respuesta durante las diapositivas. Así que mi error. Pero yo- Sí, espero que la mayoría de la gente también lo haya entendido antes de ver las diapositivas. Sí. Quiero decir, está bien, incluso si lo entendieron con tu charla, ¿verdad? Porque aprendieron algo.

Sí. Algunos lo hicieron. Como, ya sabes, se confundieron con V7.7. Vale. Pero, sí, impresionante. ¿Qué te parecen los resultados? Porque el 65% lo acertó. Sí. Bueno, creo que estamos haciendo quizás un buen trabajo de comunicación de eso. Sé que el 7.7 fue importante, porque es más o menos donde añadimos mucho más soporte a algunos de los comandos para que realmente funcionen en los espacios de trabajo. Así que los dos son muy importantes. Es solo que nunca sucedió en la versión 6. Sí.

Genial. Así que vamos a tomar algunas de las preguntas de la audiencia. Así que Sebi pregunta, ¿cuáles son los principales beneficios o inconvenientes de usar los espacios de trabajo de NPM en lugar de YARN o PNPM? Bueno, esa es una muy buena pregunta. Creo que es más una cuestión de dar opciones a los usuarios, ¿verdad? Empoderar a los usuarios para que básicamente se queden con la herramienta que les gusta, ¿verdad? Y sí. NPM ha estado por aquí durante mucho tiempo, y los espacios de trabajo es definitivamente algo que YARN inició hace mucho tiempo, y ahora estamos dando la opción a los usuarios de NPM de también tener eso bajo su cinturón, supongo. Así que es más una cuestión de elección, diría yo.

Genial. Ampliando esta pregunta, tengo otra pregunta, porque, ya sabes, como, no sé, como la voz de todos se está yendo mal ahora, supongo. Como, el clima está cambiando, lo que sea. Entonces, ¿cómo funciona el espacio de trabajo de NPM, ya sabes, en comparación con Lerna? Porque Lerna ha estado por aquí durante un tiempo. Correcto, correcto. Sí. Esa es una buena pregunta. Como, Lerna trabajó alrededor de las limitaciones de NPM antes de que NPM soportara los espacios de trabajo. Así que, básicamente era muy intensivo porque estaba haciendo una instalación para cada uno de tus espacios de trabajo. Estaba gestionando una instalación de NPM separada para cada uno de ellos y asegurándose de que todo funcionara bien juntos. Y sí, básicamente, con los espacios de trabajo de NPM, obtienes eso de forma nativa. Y, como, la CLI de NPM, cuando está instalando tu proyecto, es capaz de ser consciente de que cada uno de estos espacios de trabajo están ahí.

Y también tienen dependencias. Y puedes aprovechar eso para elevar todo a la cima, ahorrando mucho espacio si vas a duplicar muchas cosas con Lerna, ¿verdad? Entonces, definitivamente hay muchos beneficios en comparación con Lerna en la forma en que el instalador puede manejar todo como una sola cosa, como una sola instalación, asegurándose de que todo llegue al lugar correcto, y los espacios de trabajo se sincronicen correctamente para que puedan trabajar juntos. Genial, sí.

Entonces, en realidad, ayer tuvimos una gran charla de Sultan sobre pnpm. Allí, estábamos hablando de las dependencias aisladas y, ya sabes, las dependencias elevadas. Y creo que ya está en Yarn también, Yarn 3, pero es opcional, y va a ser de facto por Yarn 4. Entonces, me preguntaba, ¿tienes algo sobre, npm? ¿Está npm también, yendo por ese camino, o algo así? Sí, tenemos esto de Microsoft, que en realidad estaba trabajando en esto, cuando estamos llamándolo el modo aislado, que es básicamente para, creo que la gente está muy familiarizada con la forma en que npm hace las instalaciones, Yarn está siguiendo ese camino. Y sí, estamos trabajando en algo ahora que es equivalente a eso. Así que sí, lo llamamos el modo aislado. Y sí, creo que incluso un colega mío, como este equipo de Microsoft, creo que estábamos hablando, presentando eso en otra conferencia esta semana también, así que probablemente tendremos más noticias y más contenido para publicar hablando un poco sobre cómo va a funcionar eso. Eso es definitivamente emocionante. Me pregunto qué pasaría con el meme del objeto más pesado del universo siendo los módulos de Node. Sí, esperemos que podamos solucionar eso. Sí.

Entonces, cuéntame algo como qué es, ya sabes, lo próximo para los espacios de trabajo de npm? Porque es bastante nuevo ahora. ¿Qué sigue para esto? Sí, definitivamente algo que quería destacar. Quiero resaltar en la charla, ¿verdad? Todavía hay algunos defectos y limitaciones, así que definitivamente puedes esperar que estemos trabajando en esto muy, muy pronto. La versión de Npm ya va a tener mejoras en la próxima versión, la próxima semana. Va a añadir más características para ayudar a los espacios de trabajo a vincularse entre sí al final de la creación de una nueva versión para uno de los espacios de trabajo. Eso es algo que va a salir en la próxima versión. Y vamos a estar trabajando en añadir ese commit de git y etiqueta que falta al cortar una versión de un espacio de trabajo ahora mismo. Y uno de los principales desafíos es también abordar la posibilidad de tener un equivalente a esa opción de no elevación, de modo que si estás tratando de usar un paquete que depende de la ubicación, ese paquete va a ser como, así que si espera estar dentro de la carpeta de módulos de Node dentro de la carpeta del espacio de trabajo, puedes tener una API de primera clase muy agradable para hacer eso, ¿verdad? Tener ese soporte. Así que creo que eso es a corto plazo, definitivamente estamos buscando abordar estos. Y creo que a largo plazo va a ser estabilizar aún más. Hemos estado trabajando mucho en asegurarnos de que pulimos la herramienta desde que empezamos a enviar el soporte para cada uno de los comandos, y cómo va a integrarse con las próximas características, ¿verdad? Como el modo aislado del que hablaremos, y tenemos mucho más en camino, ¿verdad? E incluso el comando PKG, creo que también hablaron de eso en el comando, como Esto va muy bien, muy bien con los espacios de trabajo, ¿verdad? Te da más poder sobre el trabajo con todos estos paquetes al mismo tiempo. Puedes, de nuevo, establecer PKG y un valor que va a todos los espacios de trabajo. Así que, creo que definitivamente puedes esperar más sinergia entre estas nuevas características y un mejor soporte de espacios de trabajo. Sí. Genial. Veo muchas cosas interesantes sucediendo, como un gran momento para las herramientas. Muchas gracias, en realidad. Este es todo el tiempo que teníamos para preguntas y respuestas, pero para la audiencia, aún puedes hablar con Roy en su sala de conferencias, así que ve al chat especial. Y Roy, muchas gracias por esta charla tan perspicaz y por responder a todas estas preguntas. Fue un placer tenerte aquí hoy. Muchas gracias. Sí, fue un placer. Gracias. Muchas gracias. Nos vemos la próxima vez.