Monorepos basados en paquetes: Aceleración en menos de 7 minutos

Entonces, me dijeron que tengo siete minutos, así que sin código, solo diapositivas, solo código, sin diapositivas, y lo que quiero hablar un poco en esta breve charla es cómo podemos acelerar MonrayBus, ¿de acuerdo?

Entonces, lo que tengo aquí es un espacio de trabajo pmpm, y utiliza pmpm como el sistema de gestión de paquetes. Es casi lo mismo que para npm o YARN workspaces, así que no hay una gran diferencia allí. Entonces, lo que puedes ver aquí en este archivo, especificamos dónde viven nuestros paquetes, que es aquí en esta carpeta de paquetes, donde cada uno de los paquetes básicamente tiene sus propios módulos de nodo, tienen sus propias definiciones de paquete JSON, también sus propios archivos de entrada, y lo más importante aquí abajo, incluso pueden tener dependencias entre ellos, ¿verdad?

Entonces, en un escenario de MonrayBus, y este es un caso especial donde se usa muy a menudo en bibliotecas de código abierto donde quieres publicar múltiples paquetes y pueden tener algunas Si miras el repositorio de React, VEET, Vue, Angular, muchos de ellos usan estos tipos de enfoques. Entonces, ¿cómo funciona esto? Ahora, en PMPM específicamente, hay este prefijo, y eso significa que debes resolver el paquete localmente dentro de Monray pero no buscar en algún registro de MMPM, y en tu espacio de trabajo MMPM no necesitas eso, pero esa estrella allí será la misma, y eso simplemente significa que siempre quiero depender de la última versión porque está localmente en mi espacio de trabajo, ¿verdad? No hagas esto para aplicaciones de producción. Esto es solo dentro del repositorio de Monray.

Entonces, ¿dónde vive este paquete? Ahí es donde esto vuelve a entrar en juego porque puede averiguar si puede vivir en esta carpeta de ejemplos o en una carpeta de paquetes. En este caso, esta biblioteca de UI aquí. Y nuevamente, este es un paquete con algunos scripts de construcción, scripts de prueba y potencialmente autores también, y luego tenemos aquí arriba algunas aplicaciones de ejemplo. Ahora, si desarrollas esto como tu repositorio de Monray de aplicación, esto podría ser la producción real. En repositorios de Monray basados en paquetes de código abierto, esto suele ser páginas de ejemplo donde pruebas tu producto o tus paquetes, o incluso podría implementarse junto con tu documentación para algunas demostraciones en vivo. Entonces, ¿cómo ejecutas cosas en un repositorio de Monray de este tipo? Bueno, obviamente podrías ingresar a la carpeta de paquetes y simplemente ejecutar estos scripts, ¿verdad? Eso funcionaría perfectamente. Sin embargo, no es muy práctico.

Entonces, por ejemplo, PMPM tiene un concepto llamado filtros. Por ejemplo, puedo filtrar todos los paquetes en esta carpeta de paquetes y ejecutar ese script aquí, que es ese script de construcción. Así que recorre recursivamente estos paquetes. Ahora, en este caso, es una configuración simple. Así que solo tenemos dos y los construiría. Ahora, también puedo ir y construir solo uno. Por ejemplo, tengo aquí ese remix allá arriba, y apunto al script de desarrollo. Entonces eso lanzaría mi aplicación remix, y luego puede servirla en local 3,000. Y puedo navegar por mi aplicación remix aquí, ¿verdad? Así que tengo, simplemente renderiza los componentes que están aquí. Sí. Es genial. De acuerdo. Entonces, podrías preguntarte, ¿qué hay de malo en esta configuración? Y realmente no hay nada mal aquí, ¿verdad? Porque funciona, y especialmente en una configuración más pequeña, funciona perfectamente bien y escala bien. Sin embargo, ya hay algunas cosas que podríamos optimizar. Por ejemplo, estos paquetes pueden depender potencialmente entre sí. Entonces, por ejemplo, el siguiente, nuestra aplicación remix importó la lista de productos, que internamente hemos visto que depende de la biblioteca de UI. Entonces, ¿qué sucede, por ejemplo, si elimino esta carpeta, porque consumieron esta carpeta, porque en el paquete json referenciamos estos archivos, que es la salida compilada de nuestros archivos typescript. Luego, si sirvo, por ejemplo, nuevamente la aplicación remix, se rompería, porque no puede resolver esos puntos de entrada, y así se rompe, ¿verdad? Y tendría que volver a ejecutar ese filtro, reconstruirlo, y luego funcionaría. Las cosas que debo tener en cuenta para ordenar cómo construirlos, debo construir primero el UI, luego la lista de productos y luego la aplicación.

Además, si vuelvo a ejecutar este filtro, siempre se ejecutaría, ¿verdad, aunque no hayamos tocado nada, no hayamos cambiado nada? Y aquí es donde, por ejemplo, un paquete como nx entra en juego, que puede ayudarte a acelerar algunas de estas cosas.

Entonces, ¿cómo puedes instalar nx? En primer lugar, puedes simplemente ejecutar nx add latest init o agregar el paquete por tu cuenta. La ventaja de ejecutar este script aquí es que analiza tu espacio de trabajo y su estructura, y te guía a través de algunos pasos para intentar configurarlo por ti.

Por ejemplo, una de las primeras preguntas aquí es qué scripts deben ejecutarse en orden. Y acabamos de aprender que el script de construcción debe ejecutarse en orden porque necesitamos respetar ese orden de esas cosas. Así que elegiría el script de construcción aquí. A continuación, me pregunta qué tipo de scripts de esos aquí en tu paquete monorepo son cachables. Y aquí, por ejemplo, probablemente el script de construcción sería cachable. El linting, la comprobación de tipos y las pruebas, potencialmente. Por lo general, el servidor de desarrollo y los scripts de inicio no son cachables porque eso es el entorno de desarrollo que quieres iniciar. Y luego me pregunta por las salidas. Podemos omitirlas porque ya captura la mayoría de las salidas comunes, como dist y build, y ya las supervisaría para la salida allí.

Antes de sumergirnos, lo que ya podemos hacer ahora es ejecutar el comando nx-graph. Y esto nos da una descripción general de cómo se ve ahora ese monorepo. De hecho, puedes ejecutar esto incluso en una configuración de monorepo que no tenga una x. Así que simplemente ejecutas npx nx-graph y analizará las dependencias y te dará un gráfico como este, que es realmente útil para razonar sobre cómo se ve la estructura del monorepo. Luego puedes filtrar y realizar algunas operaciones interesantes aquí, pero la parte más interesante es que este gráfico es solo para visualización, pero detrás de escena, NX obviamente utiliza esto también para determinar el orden y cómo construir las cosas, para optimizarlas. Entonces, ¿qué ha sucedido cuando ejecutamos esa instalación de NX? Básicamente, lo que obtuvimos es un único paquete NX aquí y un archivo NX.json. El archivo NX.json es como tu configuración, una especie de metadatos para NX, y principalmente contiene las operaciones de caché, porque obviamente estas pueden depender en gran medida de tus propias aplicaciones y tus propias estructuras. Algunos scripts pueden no ser cachéables. Y también define una tubería donde sabe en realidad ese orden de construcción. Así que aquí le estamos diciendo que cuando ejecutes un comando de construcción, ejecuta todas sus dependencias, que es ese guion antes, para construir primero antes de ejecutarlo para el paquete en sí. Y así es como puedo ejecutar los comandos, pero puedo ejecutarlos con NX en lugar de usar los comandos de filtro de PMPM, a través de la tubería de NX. Así que puedo hacer NX, por ejemplo, construir productos de carritos increíbles. Ese es el nombre de mi paquete de productos aquí. Entonces, si entramos aquí en la lista de productos, puedes ver aquí en la parte superior este es mi nombre aquí. Y para ejecutar esa construcción aquí para nosotros. Ya puedes ver esto si me desplazo un poco hacia arriba, esta tarea de ejecutar un producto dependiente primero, que se completó correctamente, ¿verdad? Y luego está nuestra biblioteca de interfaz de usuario. No me muestra la salida porque no me interesa realmente. Así que PMPM anteriormente me mostraba toda la salida porque simplemente ejecuta las tareas. Pero en realidad solo me interesa esta construcción de productos. Ahora esto resulta ser un efecto secundario que primero necesito construir esa biblioteca de interfaz de usuario. Y de manera similar, obviamente también puedo ejecutar, hagamos la ejecución múltiple, digamos ejecutar múltiples tareas en todos los paquetes que tengo. Por ejemplo, construir, lintear y testing, y qué otros tipos podría tener potencialmente. Y si ejecuto eso, también puedes ver que muestra una buena salida de iterar sobre las cosas sin mostrarte cada salida detallada. Porque realmente no estás interesado en eso a menos que falle. Si falla, te lo mostraría, ¿verdad? Y además, aquí arriba puedes ver que ya ejecutamos la construcción de productos y la interfaz de usuario anteriormente. Así que no las ejecuta de nuevo, sino que las almacena en caché, por lo que es más rápido. De hecho, si vuelvo a ejecutar esto desde cero, las almacenaría en caché desde el principio. Y eso es todo. Solo estamos rascando la superficie, obviamente. Así es como puedes agregar NX en un monorepo basado en paquetes simples. Y a partir de ahí puedes expandirte aún más. Así que puedes agregar automatización encima. Una cosa común es, a menudo, una vez que tienes una estructura de paquetes como esta, quieres generar varios de ellos porque no quieres copiar y pegar cada vez. Y NX también ofrece opciones en ese sentido. Eso suena interesante. Conéctate conmigo aquí. También tenemos un stand afuera, así que ven y también podemos profundizar en este tipo de cosas. Gracias.