Potenciando los Monorepos con los Espacios de Trabajo de npm

Hola, y bienvenidos a la Masterclass de NPM Workspaces. Permítanme comenzar presentándome. Mi nombre es Rui Adorno. Soy un desarrollador de software en el equipo de NPM CLI de GitHub. He estado trabajando en NPM CLI durante casi tres años. Trabajo en la reescritura de NPM v7 y muchas de las características de las que hablaremos hoy, especialmente los espacios de trabajo. Estoy muy emocionado de compartir parte de ese trabajo con ustedes hoy.

Y comencemos con una descripción general de lo que vamos a cubrir hoy. Comencemos con una introducción a qué son los Espacios de Trabajo de NPM y luego cubriremos algunos ejemplos prácticos que se acerquen lo más posible al uso en la vida real, y también mencionaremos algunas de las cosas a las que deben estar atentos. Así que, empecemos.

Los Espacios de Trabajo de NPM. ¿Qué es eso? Comencemos con los Espacios de Trabajo, que es básicamente un 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 general que le dimos al conjunto de características que te ayudan a lograr eso. Básicamente te ayuda a gestionar múltiples paquetes anidados dentro de un solo paquete de nivel superior. Por lo tanto, te ayudará a centralizar la instalación de todas las dependencias en una sola carpeta de Node Modules, por lo que también terminarás teniendo solo un archivo de registro 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 desde el lado técnico, también puedes centralizar, tener un solo lugar para ejecutar todas tus pruebas, pares, linting, cualquier cosa que puedas imaginar. Necesitas tener todo junto para que tu proyecto funcione con todos los paquetes. Puedes tenerlo todo en un solo lugar. Por lo tanto, puede ser de gran ayuda dependiendo del estilo del proyecto que estés tratando de lograr. Otra cosa que me gustaría mencionar aquí es la línea de tiempo, solo para dar un poco de noción de cómo hemos estado mejorando iterativamente en 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 los Espacios de Trabajo de NPM. Y luego, en la versión 7.7, otro gran avance que introdujo las propiedades de configuración de un espacio de trabajo o que apuntan a todos los espacios de trabajo y el primer comando que los admite con NPM run y NPM exec. No hubo muchos 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.

Entonces, comencemos con algunos ejemplos aquí. Tengo este proyecto que tengo a la izquierda aquí, que es una aplicación de muestra que he creado tratando de acercarme lo más posible a un proyecto de la vida real. Es una especie de aplicación web que consta de dos servicios diferentes. Puedes ver que tengo mi servicio de sincronización de usuarios, mi servicio de aplicación web e incluso configuro un tercer espacio de trabajo aquí, que son las diapositivas que estás viendo ahora mismo. Todos forman parte de este monorepo que estoy gestionando aquí.

Y con eso, espero poner algunos ejemplos que se acerquen mucho a cómo usarías esto en tu vida real. Así que puedes ver que todos tienen un montón de dependencias aquí usando Next.js, los servicios usando Fastify. Así que puedo comenzar rápidamente ejecutando npm ls aquí y podemos ver cómo, y ls es un comando que conoce los espacios de trabajo y resaltará cada uno de los espacios de trabajo en mi proyecto e incluso enumerará las dependencias de cada espacio de trabajo cuando ejecute un npm ls. Por lo tanto, es el primer comando que tiene soporte de primera clase para los espacios de trabajo.

Avanzando aquí, me gustaría resaltar npm init. Probablemente sea la mejor manera de comenzar tu espacio de trabajo porque se asegurará de que cada paso necesario esté presente. Básicamente, todo lo que necesitas para rastrear un paquete anidado como un espacio de trabajo es asegurarte de tener la carpeta con un archivo package JSON dentro de ella, dentro de tu proyecto, y luego agregar el nombre de la carpeta a tu campo de workspaces en tu archivo package JSON en el nivel superior. Por lo tanto, usar npm init se asegurará de que esos requisitos estén presentes. 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 llamaré `website`. Así que puedo ejecutar npm init, estoy usando -Y aquí para aceptar todas las opciones predeterminadas y estoy apuntando a un sitio web. Eso creará una carpeta `website` con un archivo package.json dentro de ella, y mostrará el contenido del archivo package.json aquí. Y como mencioné antes, el otro punto realmente importante que npm init se encarga es colocar la referencia al `website` dentro de mi archivo package.json en mi carpeta de nivel superior. Con eso, todo está configurado. Si ejecuto npm install aquí, ahora el árbol de instalación rastreará el `website`. Y si vuelvo a ejecutar npm ls, veré que `website` está listado como uno de los espacios de trabajo aquí resaltado en verde. Esa es definitivamente la forma recomendada de comenzar con un nuevo espacio de trabajo dentro de tu proyecto.

Y podemos pasar a otro aspecto muy importante. ¿Cómo agregas dependencias a uno de tus espacios de trabajo, ¿verdad? Un ejemplo rápido aquí, nuevamente, voy a cambiar la configuración del espacio de trabajo aquí. Así que puedes ver que prácticamente puede ir a cualquier lugar. Simplemente puedo declarar el espacio de trabajo de npm. Voy a apuntar al sitio web que acabo de crear. Y digamos 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 paquete Simple Slider desde el registro. Lo va a colocar como una dependencia de mi espacio de trabajo del sitio web. Puedo buscar su package.json. Y puedo ver que Simple Slider está declarado aquí como una dependencia. Pero si busco en la carpeta node_modules en el nivel superior de mi aplicación monorepo, puedo ver que Simple Slider se colocó allí. Básicamente, ese es uno de los conceptos más importantes de los espacios de trabajo de npm: todo intenta ser elevado tanto como sea posible. Solo evita esa elevación o ese traslado de un nivel cada dependencia si encuentra duplicaciones. Así que si hay duplicaciones, es posible que termines con una carpeta node_modules dentro de tu espacio de trabajo que deduplica esos paquetes para que funcione como se espera. Así que todo eso para mencionar una cosa que he visto como algo común con los espacios de trabajo es que algunas personas solían tener esta opción de configuración no hoist que era una opción que Yarn introdujo para básicamente hacer que los espacios de trabajo dijeran: `De acuerdo, necesito esta dependencia, pero necesito asegurarme de que esté dentro de una carpeta node_modules dentro de mi espacio de trabajo`. Debido a la naturaleza de algunos módulos, algunos paquetes, realmente necesitan depender del hecho de que están en esa posición en el sistema de archivos. Eso es algo con lo que ya te encuentras para básicamente dar una salida a los usuarios para tener un poco más de control sobre dónde se coloca en sus dependencias. Para los espacios de trabajo de npm, actualmente estamos siguiendo eso como una nueva función. Lo estamos discutiendo en nuestros procesos de RFC. Y estamos deseando proporcionar a los usuarios una forma de hacerlo. Aún no estamos seguros si vamos a usar ese mismo valor de configuración no-hoist, o si será algo diferente. Pero mientras tanto, quería proporcionar una forma de desbloquearte si alguna vez te encuentras con ese escenario. En mi aplicación de muestra aquí, realmente me encontré con eso. Estoy usando este Prisma Client, que es esta biblioteca para administrar, básicamente, es un ORM para esa base. Y lo estoy usando en ambos servicios de mi aplicación de muestra. Y cuando se elevó al nivel superior de mi aplicación, básicamente no funcionó. Una forma rápida de desbloquearme y hacer que funcione es duplicarlo y tenerlo en ambas carpetas de mis servicios, dentro de sus node_modules. Así que una forma rápida de lograr esa duplicación fue básicamente poner algún paquete simulado aquí, que básicamente entraría en conflicto con el espacio de nombres del paquete que están usando. Así que he usado Prisma y Prisma Client, y los he declarado usando alias de NPM y apuntando a algo más.

En mi caso aquí, estoy usando este módulo abraham, pero realmente puede ser cualquier cosa. Y esto es para asegurarme de que cuando lo declare en mi servicio de usuario, tenga la declaración correcta de las versiones esperadas que tengo para estas bibliotecas. Para que cuando NPM instale, realmente coloque las carpetas del cliente Prisma dentro de mis módulos de nodo de usuario. Es básicamente una forma de forzar ese mismo comportamiento de no elevación y podría ayudar a bloquear a otros usuarios allí, por lo que es una forma muy práctica de comenzar 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.

Avanzando, también quiero cubrir la ejecución de scripts y aquí también coloco algunos ejemplos de cómo puedes ejecutarlos. Puedes ejecutarlos utilizando el nombre del espacio de trabajo, también un ejemplo si tu espacio de trabajo tiene un ámbito, entonces también debes definir el ámbito, pero también puedes llamarlo utilizando el nombre de la ruta del espacio de trabajo.

Básicamente, en mi proyecto aquí, puedo mostrar rápidamente si apunto a ese espacio de trabajo de servicio de sincronización de usuarios que tengo y ejecuto sus pruebas, puedes ver que se ejecutarán las pruebas para ese espacio de trabajo y es básicamente lo mismo que navegar hasta la carpeta de ese espacio de trabajo y ejecutar npm test dentro de él. Sí, y básicamente 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 manera que puedan ser mucho más útiles.

Comenzando rápidamente aquí, siguiendo el ejemplo de prueba que acabo de dar. Este es un ejemplo. Estos son los scripts de mi archivo package JSON de nivel superior. Estoy declarando esta columna de prueba para la aplicación web y esta columna de prueba para el usuario, nombrada según cada uno de mis espacios de trabajo. Así que básicamente llaman a las pruebas y apuntan a cada uno de los espacios de trabajo. De esta manera, tengo estos múltiples scripts en mi comando de nivel superior. Voy a utilizar este archivo binario run-ass que en realidad proviene de este paquete de usuario llamado npm run all. Lo anoté aquí. Es un paquete muy útil. Te ayuda a ejecutar múltiples scripts y te brinda mucha más flexibilidad en la forma en que lo haces. Básicamente, le estoy diciendo a run-ass que ejecute todos mis objetivos de prueba definidos aquí en mi archivo. Así que volvamos a mi carpeta raíz aquí y ejecutemos npm test y veamos qué sucede. Puedes ver que se ejecuta primero el objetivo de prueba de la aplicación web, que ejecuta la prueba dentro de ese espacio de trabajo. Y luego, después de eso, ejecutas 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. Un poco más evolucionado, pero siguiendo el ejemplo anterior, también ejecutemos mis servidores de desarrollo aquí. Tengo algo similar, dev para la aplicación web y para usersync, y estoy apuntando a npm run en mis espacios de trabajo y ejecutando el script de desarrollo de cada uno de ellos. Pero la particularidad de los servidores es que necesito que todos estén en ejecución al mismo tiempo, ¿verdad? Esto también es algo proporcionado por npm run all, que voy a usar para ejecutar, usando run-p, que va a ejecutar ambos objetivos en paralelo. Simplemente los iniciará todos al mismo tiempo, los mantendrá en ejecución para que pueda tener todo en funcionamiento y realmente usar mi servidor de desarrollo, navegar por mi interfaz de usuario. Así que probémoslo rápidamente aquí. Voy a ejecutar npm run dev. Puedes ver que ejecuta todos los scripts y sus dependencias. Voy a avanzar aquí. Esta siguiente diapositiva en realidad apunta al servidor que se está ejecutando en mi localhost. Y ahora, una vez que todo esté en funcionamiento, puedo ver que mi lista de usuarios está de vuelta. Puedo ver algunos usuarios, puedo hacer clic, navegar, y puedo ver que mi aplicación web funciona como se esperaba. Aquí quiero resaltar este nuevo comando, algo nuevo.

Lo introdujimos a finales del año pasado en la versión 7.20, y es un comando que te ayuda a establecer y recuperar claves y valores de tus archivos package.json. No solo es útil en el contexto de los espacios de trabajo, sino que es súper útil cuando se utiliza en el contexto de los espacios de trabajo.

Se puede utilizar para, déjame resaltar aquí rápidamente. Si ejecutas npm pkg get, puede ser solo un paquete simple. Básicamente imprimirá el contenido de package.json. Y también puedes filtrar las propiedades, digamos, el nombre, y luego obtengo el nombre de mi paquete allí.

Cuando se agrega el soporte para las propiedades de los espacios de trabajo, puede volverse realmente poderoso. Como en este ejemplo aquí, voy a recuperar el nombre de la versión de todos mis espacios de trabajo. Esta opción de configuración aquí, --WS, es básicamente una forma de decir, ok, apunta a todos mis espacios de trabajo configurados. Si lo ejecuto, puedes ver que devuelve el nombre de la versión de cada uno de mis espacios de trabajo. Y incluso están clasificados por el nombre del espacio de trabajo. Así que puede ser realmente útil.

Y también para resaltar un poco más cómo pueden ser útiles, déjame también establecer algunos datos en estos archivos package.json. Digamos que estoy gestionando este proyecto y es un proyecto de código abierto. Solo quiero mostrar información sobre cómo los usuarios pueden financiar mi trabajo. Así que puedo usar npm pkg set. Y digamos que voy a establecer una clave de financiamiento en todos estos package.json. Luego lo voy a vincular a mi URL de patrocinadores de GitHub y voy a apuntar a todos los espacios de trabajo configurados. Así que puedo ejecutar eso. Y si buscas, digamos, mi package.json de usersync, puedes ver que la información de financiamiento está ahí ahora. Lo mismo ocurre con mi package.json de la aplicación web. Puede ser una forma increíblemente poderosa de ayudarte a gestionar todos esos datos en tu package.json en todos los espacios de trabajo configurados.

También quiero destacar aquí que npm version y npm publish también admiten espacios de trabajo. Entonces, si quieres crear, digamos, una nueva versión de parche de un espacio de trabajo, eso es posible hoy. Y algo a tener en cuenta es, como puedes ver aquí, aumenté mi versión a v1.0.1. Puedo buscar mi package.json allí y ver que la versión está ahí, pero una cosa a tener en cuenta que es un poco diferente ahora de la forma en que npm version funciona de forma predeterminada es que no hay muchas confirmaciones y etiquetas cuando se ejecuta npm version. Así que es algo a tener en cuenta, pero definitivamente puedes esperar mejoras en npm version específicamente.

Para resumir todo, quería hacer un ejemplo rápido aquí. Estoy usando npm exec. Es básicamente npx.

Se promocionó como un subcomando en la CLI de npm desde la versión siete. Y quería crear rápidamente otro espacio de trabajo. Llamémoslo imprimir el directorio de trabajo actual. Y voy a usar exec para ejecutar este espacio de trabajo como un comando en todos los demás espacios de trabajo que tengo configurados, juntando todo usando todos los comandos que acabamos de ver.

Así que déjame ir rápidamente a esa carpeta y comenzar el archivo index.js. Este archivo index.js simplemente imprimirá el directorio de trabajo actual. Esto será útil porque quiero resaltar cómo funciona npm exec o npm run. Se ejecutan en el contexto de cada carpeta. Así que quiero imprimir el directorio de trabajo actual solo para asegurarme de eso. La próxima vez, voy a establecer un valor binario de Index.js para el espacio de trabajo imprimir CWD que acabo de crear, para que se rastree correctamente ese archivo binario, Index.js. Y ahora voy a instalar npm para juntarlo todo, asegurarme de que mi binario esté correctamente vinculado a mi carpeta de módulos de Node. Y ahora puedo ejecutar npm exec y voy a llamar a mi módulo y le diré que se ejecute en cada uno de los espacios de trabajo. Y puedes ver que obtuve el resultado esperado aquí. Básicamente, imprimió la ruta de cada uno de mis espacios de trabajo cuando se ejecutó dentro de ellos. Así que aquí tienes un ejemplo rápido para cerrar, resumir y juntar todo, cómo puedes usar todos estos comandos.

Si quieres obtener más información al respecto, definitivamente consulta la documentación oficial. Tenemos una sección exclusiva sobre los espacios de trabajo, pero también hay documentación sobre cada uno de estos comandos que explica un poco más cómo usarlos. Y si quieres encontrarme, soy Rui Adorno en Twitter o GitHub. Y aquí también está mi sitio web. Realmente espero que esto haya sido útil y que los ejemplos de la vida real sean muy buenos. Espero que lo disfrutes. Gracias. ♪♪