Monorepos de Node con Nx

Rate this content
Bookmark
Github

Varias apis y varios equipos en el mismo repositorio pueden causar muchos dolores de cabeza, pero Nx te tiene cubierto. Aprende a compartir código, mantener archivos de configuración y coordinar cambios en un monorepo que puede escalar tanto como tu organización. Nx te permite dar estructura a un repositorio con cientos de colaboradores y elimina las desaceleraciones de CI que normalmente ocurren a medida que crece la base de código.


Índice de contenidos:

- Laboratorio 1 - Generar un espacio de trabajo vacío

- Laboratorio 2 - Generar una api de node

- Laboratorio 3 - Ejecutores

- Laboratorio 4 - Migraciones

- Laboratorio 5 - Generar una biblioteca de autenticación

- Laboratorio 6 - Generar una biblioteca de base de datos

- Laboratorio 7 - Añadir un cli de node

- Laboratorio 8 - Limites de módulo

- Laboratorio 9 - Plugins y Generadores - Introducción

- Laboratorio 10 - Plugins y Generadores - Modificación de archivos

- Laboratorio 11 - Configuración de CI

- Laboratorio 12 - Caché distribuida

Isaac Mann
Isaac Mann
160 min
06 Apr, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta masterclass explora los Monorepos de Node con NX, destacando los beneficios de los monorepos y NX en la gestión de la complejidad, el intercambio de código y la gestión de dependencias. Cubre la creación y uso de bibliotecas, la configuración de límites de módulo, el linting y la integración de CI/CD. La masterclass también introduce NX Cloud, que ofrece caché distribuida y ejecución de tareas para mejorar el rendimiento. En general, la masterclass proporciona ideas prácticas y herramientas para un desarrollo y una ingeniería de software eficientes en un entorno de monorepo.

Available in English

1. Introducción a Node Monorepos con NX

Short description:

Bienvenidos a Node Monorepos con NX. Esta masterclass estará orientada hacia Node como el marco de trabajo utilizado con NX. NX es agnóstico en cuanto a marcos de trabajo y lenguajes, lo que te permite utilizar aplicaciones de front-end como React o Angular, así como otros lenguajes como Java y Python. Los Monorepos ofrecen beneficios como cambios atómicos, fácil compartición de código y gestión simplificada de dependencias.

Muy bien, bienvenidos a Node Monorepos con NX. Esto es genial. Entonces yo soy, mi nombre es Isaac Mann. Soy un arquitecto en NX. Hemos estado, he estado trabajando con NX durante cuatro años. He sido empleado de NX durante cuatro años. Lo utilicé durante dos años antes de eso. Y sí, esto es emocionante. Así que esta masterclass estará orientada hacia Node como el marco de trabajo que estaremos utilizando con NX. Pero NX es, ya sabes, es prácticamente marco de trabajo y lenguaje agnóstico. Pero entraremos en eso más adelante. Así que es, ya sabes, puedes utilizar aplicaciones de front-end como React o Angular o ya sabes, cualquier otra tecnología de front-end que estés utilizando. Tú también puedes utilizar otros lenguajes como obviamente la gente utiliza Java y Python y .NET con NX. Así que NX se trata de, ya sabes, gestionar tu base de código y cualquier código que estés utilizando es esto es Node monorepos con NX. Y primero, vamos a empezar con una pequeña discusión de, por qué querrías un monorepo. Así que un monorepo es cualquier repositorio que tiene más de una aplicación viviendo en esa, en esa base de código. Entonces, ¿cuál es el beneficio de un monorepo? Así que tres categorías grandes de beneficios para monorepos. Monorepo te da cambios atómicos, te permite compartir fácilmente tu código y te da un único conjunto de dependencias, facilitando la gestión de esas dependencias. Así que vamos a profundizar en cada una de estas tres cosas y explicar

2. Beneficios de Monorepo y NX

Short description:

Un monorepo ofrece beneficios como cambios atómicos, fácil compartición de código y gestión simplificada de dependencias. Permite una ejecución de comandos más rápida, pruebas dirigidas para proyectos afectados y almacenamiento en caché local y distribuido. NX proporciona herramientas para ayudar a lograr los beneficios de un monorepo sin los inconvenientes de la colocación de código. Permite compartir código de manera controlada y una gestión eficiente de las dependencias.

qué son y por qué son beneficiosos. Entonces, si tuvieras una aplicación y una especie de biblioteca que es utilizada por esa aplicación. Y si los gestionas en dos repositorios separados, digamos que haces un cambio en la biblioteca UI que está en el repositorio dos en la parte inferior aquí. Si haces un cambio en ella, y por alguna razón rompe la aplicación de la página de inicio, el ciclo de vida de ese cambio sería que alguien hace un cambio en la biblioteca común UI. Suben el commit, en algún momento después alguien intenta usar esa nueva versión de la biblioteca común UI en la aplicación de la página de inicio. Se dan cuenta de que hay un cambio que rompe su aplicación. Entonces presentan un error con la biblioteca común UI, y dicen, Oye, tienes que arreglar esto. Y luego, una vez que el desarrollador de la biblioteca UI ve ese problema, hacen el cambio, suben una nueva corrección, una nueva versión, y luego las personas de la aplicación de la página de inicio tienen que actualizar la versión a la versión corregida, y luego ver si arregló su aplicación. Así que ese ciclo completo, normalmente, en el mejor de los casos tarda unos días, puede llevar una semana o dos si las personas no están trabajando en estas cosas a tiempo completo. Entonces, uno de los problemas aquí es, si pusieras ambas, la biblioteca y la aplicación juntas en el mismo repositorio, entonces ese ciclo sería, sería solo el creador de la biblioteca UI, haciendo un cambio, ejecutando las pruebas y viendo Oh, rompí las pruebas en la aplicación de la página de inicio, tengo que arreglar eso. Y eso, ese ciclo tomará como media hora o una hora. Incluso antes de que hayas subido un PR, te darías cuenta de que rompiste la aplicación, tienes que modificar tu code. Entonces, tienes en un PR, ya sabes, todos los cambios que necesitas hacer a la aplicación o los cambios que necesitas hacer en la biblioteca UI para adaptarse a la aplicación. Eso es un beneficio de un monorepo. El segundo beneficio es compartir code. Digamos que tienes alguna lógica sobre qué es un nombre de usuario válido. Y esta función, obviamente, en diferentes escenarios, tendrías una función más compleja que esta, estás manejando si el nombre de usuario es válido. Pero digamos que quieres compartir esto a través de tu aplicación a través de múltiples aplicaciones, múltiples bibliotecas. Si esto alguna vez cambiara, tendrías que actualizar eso en cada repositorio que lo esté utilizando. Si estás copiando el code de repositorio a repositorio, mientras que si estás en un entorno de monorepo, puedes simplemente usar esta función. Y cuando esa función cambia, entonces tu comportamiento cambia en todo el repositorio, donde sea que se esté utilizando. Así que compartir code fácilmente. La tercera cosa es tener un único conjunto de dependencias. Entonces, si tienes un framework como Node, o en este caso, en la imagen es react, si tienes diferentes versiones de ese framework siendo utilizadas en diferentes aplicaciones, puedes encontrarte con errores de tiempo de ejecución muy extraños y difíciles de debug. Y, y tener tu code en el mismo repositorio básicamente te obliga a tener, bueno puedes establecer reglas para obligarte a estar en la misma versión para todo lo que está en ese repositorio. Es posible tener múltiples versiones del mismo monorepo, pero es, es mejor tener una sola versión y facilitar las cosas a largo plazo. Así que básicamente en un entorno grande cuando tienes múltiples aplicaciones, normalmente tienes una aplicación en la que estás trabajando todo el tiempo, que está en la última versión de las dependencias que tienes, pero si vas a tener, ya sabes, dos o tres otras aplicaciones que se trabajan tal vez una vez cada par de meses y esas inevitablemente se quedan atrás y tienes que recordar, ¿cómo actualicé ese framework? Um, ya sabes, esto, la actualización de hace seis meses, y tienes que recordar y pasar por todo ese mismo trabajo de nuevo. Um, mientras que si estuvieras actualizando todas tus aplicaciones, todas tres aplicaciones al mismo tiempo, es mucho más fácil que actualizar tres aplicaciones diferentes, en diferentes momentos a lo largo de un año y medio. Um, así que lo haces todo de una vez y es mucho más fácil que hacerlo repartido en un año o cuando pienses en actualizar esas aplicaciones. Bien. Entonces, una forma de, ya sabes, tener un monorepo, um, la diferencia entre un monorepo y la colocación de code y la colocación de code es cuando simplemente juntas todas las aplicaciones en el mismo repositorio sin tener ninguna tooling para gestionar eso. Y eso, eso puede ser una pesadilla. Si simplemente lo juntas todo, um, puedes terminar con un escenario en el que estás ejecutando pruebas innecesarias. No tienes límites de code y todo el code se mezcla y es difícil de mantener. Um, y puedes tener tooling inconsistente donde tienes conflictos entre cómo esas herramientas interactúan entre sí como tus herramientas de testing o tus otras herramientas que tengas. Um, entonces, hablemos de ejecutar pruebas innecesarias. Digamos, um, que tienes una biblioteca llamada la página de inicio del producto. Um, que está utilizando el producto compartido UI. Si hicieras un cambio solo en el proyecto de la página de inicio del producto, um, sabes que necesitas ejecutar las pruebas para ese proyecto para asegurarte de que no rompiste nada. Pero, ya sabes, también sabes que no tienes que ejecutar las pruebas en el producto compartido UI porque, ya sabes, no hay forma posible de que puedas haber roto la prueba en el producto compartido UI. Si lo único que cambiaste fue este proyecto superior. Entonces, si no tienes ninguna tooling configurada en tu repositorio, que entienda tu gráfico de dependencias aquí, um, y para asegurarte de que no rompiste nada, tendrías que ejecutar las pruebas para todo en tu repositorio. Um, cada vez que haces un cambio en cualquier lugar en tu repositorio. Um, sería mejor tener alguna tooling para entender que solo necesito ejecutar pruebas en la página de inicio del producto, no en el producto compartido UI. Y esto obviamente es un, ya sabes, es un escenario muy simple, un repositorio real. Y este es incluso un pequeño ejemplo de repositorio aquí, este ejemplo, um, una configuración más típica sería algo como esto, donde tienes muchos nodos diferentes y necesitas algún, ya sabes, algún ordenador para entender qué pruebas realmente necesito ejecutar en lugar de tener a una persona tratando de recordar todas estas diferentes líneas del gráfico de dependencias. Um, para saber que tienes que ejecutar estas pruebas y no estas pruebas. Um, quieres asegurarte de ejecutar todas las pruebas que necesitas ejecutar, pero no las pruebas que no tienes que ejecutar. Bien, número dos, no hay límites de code. Entonces, si simplemente juntas todo, um, podrías tener algún code que escribas para, en tu biblioteca UI, que solo está destinado para que lo uses tú mismo, um, para que lo uses dentro de ese proyecto. Y no estás listo para que otras personas empiecen a usarlo todavía. No quieres mantener esa superficie de API. Um, pero no hay nada que impida a las personas entrar en tu, um, tu proyecto y, y usar alguna función que solo quieres para ti. Pero ellos dicen, Oh, hay code que me gusta, quiero usarlo. Y ahora porque lo están usando, estás atrapado manteniendo esa API y no puedes cambiar ella. Um, porque si la cambias, romperás su aplicación. Um, entonces necesitas alguna tooling configurada para decir, estas son las funciones que estoy, que estoy bien con que otras personas usen, y estas son funciones que son puramente internas y solo para, para mis proyectos, um, para usar.

3. Beneficios de NX en Monorepos

Short description:

NX proporciona herramientas consistentes para gestionar la complejidad en monorepos. Ofrece una ejecución más rápida de comandos, pruebas selectivas para proyectos afectados, almacenamiento en caché local y distribuido, compartición de código controlada, prácticas de codificación consistentes y diagramas de arquitectura precisos. Para crear un nuevo espacio de trabajo, ejecuta NPX create NX workspace y proporciona un nombre. NX establece el directorio, el alias de ruta y el ámbito de MPM en función del nombre proporcionado. En el laboratorio uno, generaremos un espacio de trabajo NX vacío llamado BG-Horde para la empresa ficticia BoardGameHorde.

Um, lo otro es que puedes tener cualquier tooling consistente. Entonces, normalmente con los scripts de MPM, simplemente se les da nombres al azar y se lanzan un montón de banderas. Y nadie sabe exactamente qué hacen todas las banderas. Nadie sabe realmente qué hacen todos los scripts. Así que tienes, ya sabes, diferentes versiones de build y test y serve y Lint. Y, ya sabes, están configurados para diferentes escenarios y diferentes eventualidades. Pero es realmente difícil a menos que estés trabajando en ese proyecto todos los días. Es realmente difícil saber qué hacen realmente todos esos scripts. Así que sería bueno tener, ya sabes, algunas reglas consistentes y, ya sabes, algunas convenciones sobre cómo deberían llamarse esas cosas y, ya sabes, y cómo saber fácilmente qué necesita cada bandera en esos scripts. Bien. Así que necesitas algunas, algunas tooling para ayudarte a gestionar esa complejidad. Eso es lo que NX puede hacer. NX es una tooling que te ayuda a obtener todos los beneficios de un monorepo sin los aspectos negativos de la colocación de código. Bien. Así que NX te proporciona una ejecución más rápida de comandos. Entonces, los ejecutores son básicamente, ya sabes, como scripts de NPM, que pueden ayudarte, ya sabes, a ejecutar tu, ya sabes, tu build y test y Lint y todas las acciones que tomas en tu código. NX affected es la herramienta que te permite ejecutar las pruebas solo para los proyectos que se ven afectados por un cambio de código y no las pruebas que no están relacionadas. Y luego tenemos el almacenamiento en caché local y distribuido. Entonces, cada vez que ejecutas un comando, y, ya sabes, si ejecutas ese mismo comando nuevamente sin cambiar el código, simplemente utiliza, en lugar de ejecutar realmente el build nuevamente, simplemente utiliza la versión en caché de eso, ya sabes, de esa salida y, ya sabes, sin ejecutar realmente el build nuevamente. Así que si tu build tarda, ya sabes, un minuto y medio, si ejecutas ese build nuevamente, en lugar de tardar un minuto y medio, tardará un segundo o dos solo para obtener esos datos de la caché y reproducir la salida del terminal para ti. Eso es solo a nivel local. Eso es completamente gratuito. Eso está en el NX de código abierto. Luego, con NX Cloud, puedes usar el almacenamiento en caché distribuido. Así que ese mismo comportamiento de caché que obtienes, ya sabes, en tu propia máquina, puedes compartir esa caché en toda tu organización. Así que si alguien en cualquier lugar ha ejecutado este comando con este mismo código, puedes usar su caché y reproducirla tú mismo. Así que esto, ya sabes, especialmente para los PRS, ejecutas tu código, lo subes. Se ejecuta en CI y luego otra persona verifica esa rama en su máquina y ejecuta lo mismo. Pueden, ya sabes, simplemente usar tu versión en caché en lugar de ejecutar ese mismo, ya sabes, cálculo en su máquina nuevamente. Así que básicamente solo ejecutas, ya sabes, las acciones para un conjunto particular de código una vez en toda tu organización, lo cual es, ya sabes, y eso también no solo es para, ya sabes, eso se divide por proyectos. Así que si tienes, ya sabes, una aplicación que depende de cinco bibliotecas diferentes, ya sabes, el paso de construcción de la biblioteca también está en caché, así como los pasos de construcción de la aplicación. Así que digamos que cambias solo la aplicación, la salida de construcción de esas cinco bibliotecas ya está en caché para ti. Y luego, puedes usar esa caché y luego solo hacer el último paso de construcción de la aplicación, lo cual puede ser un cambio de juego para bases de código grandes. NX también te brinda una compartición de código controlada. Entonces, configuras un archivo index.ts en la raíz de cada proyecto. Y dices que todo lo exportado desde este archivo index.ts está disponible para que otras personas lo usen. Pero cualquier cosa que no esté exportada desde ese index.ts no se te permite acceder y usarla. Puedes configurar un sistema de etiquetado para decir que estos proyectos en particular pueden depender de otros proyectos. Y es muy flexible. Puedes configurar tu propia estructura de cómo funcionan esas etiquetas. Entonces, estas bibliotecas pertenecen a este equipo. Y estas bibliotecas pertenecen a este otro equipo, este otro equipo. Y luego estas bibliotecas se comparten y pueden ser utilizadas por ambos. Puedes configurar toda esa estructura tú mismo. Puedes publicar fácilmente bibliotecas en MPM y puedes usar el archivo de propietarios de código para requerir esta función de GitHub, esta función de revisión de un cierto grupo de personas, si cambias código dentro de esa área. Así que puedes controlar cómo se gestiona ese código.

El tercer beneficio son las prácticas de codificación consistentes. Entonces, tienes algunas reglas de Lint para ayudar a gestionar la estructura. Puedes escribir generadores de código para automatizar los pasos que los desarrolladores realizan una y otra vez. Hay complementos que son creados por NX y complementos creados por la comunidad que tienen estos generadores y ejecutores escritos para ti. Así que los complementos te ayudan con, básicamente, puedes dejar de preocuparte por tu sistema de construcción. Si quieres, puedes tener el administrador de complementos del sistema de construcción y luego hacer las modificaciones que necesites para tu aplicación en particular. Los complementos también te ayudan a automatizar el proceso de actualización. Entonces, cuando hay una nueva versión de Node que sale, si hay un cambio incompatible o si hay una nueva versión de Express o cualquier otra cosa, hay un script de migración que puede actualizar automáticamente tu código para manejar cualquier cambio incompatible que ocurra. Y lo mismo ocurre con los complementos de la comunidad, hay complementos de la comunidad que cubren casos de uso que NX no cubre.

Luego, la otra cosa es que NX te brinda un diagrama de arquitectura preciso de cómo tus proyectos dependen entre sí. Esto es útil para el comando NX affected, pero también es útil para ti mismo para ver realmente, okay, cuál es la arquitectura real de mi código en lugar de la arquitectura que desearía que tuviera mi código, o la arquitectura que tenía mi código hace dos meses cuando alguien dibujó un diagrama. Así que NX realmente entiende tu código y puede dibujar las líneas de dependencia conectadas entre tus proyectos en función de lo que realmente está allí, tú o algún arquitecto realmente desearía que estuviera allí, o pensó que debería estar allí. Así que sí, esta es una estructura de archivo NX típica. Realmente tu estructura de archivos puede ser lo que quieras, pero básicamente, la forma en que la configuraremos será, tendremos una carpeta gist y una carpeta libs. Y sí. Dist es donde se construyen tus aplicaciones, tools es para scripts y cosas de ayuda. Workspace.JSON ya no es válido. NX.JSON es tu configuración de nivel de raíz para NX en sí. TS config establece un script, una ruta y luego configuras, ya sabes, rutas para tus bibliotecas para poder referenciarlas e importarlas en aplicaciones. O todas las diferentes configuraciones que tiene NX, hay nivel de espacio de trabajo y nivel de proyecto. La configuración a nivel de proyecto heredará la configuración a nivel de espacio de trabajo. Lo mismo, ya sabes, si tiene una configuración de TypeScript diferente que necesita, lo mismo para Jest y Prettier y todas las demás herramientas que NX puede configurar para ti.

Bien, eso fue mucho hablar. Vamos a comenzar creando un nuevo espacio de trabajo. Para crear un nuevo espacio de trabajo, ejecutas NPX create NX workspace, o puedes hacer lo mismo con YARN o PMPM, y le das un nombre. En este caso, el nombre establece tres cosas diferentes. Establecerá en qué directorio estás colocando tu código. Te dará el alias de ruta para importar código dentro de las cosas. Y luego, si alguna vez publicas tu biblioteca en MPM, el ámbito de MPM estará en mi org, barra, cualquier biblioteca que tengas. Cada una de estas tres cosas se puede cambiar después del hecho. Pero cuando configuras inicialmente tu espacio de trabajo, lo que escribas después de Create NX Workspace se establecerá en esas dos cosas. Bien. Así que empecemos con el laboratorio uno. Bien. Así que este repositorio aquí, no necesitas clonar este repositorio. Porque vamos a crear un repositorio completamente nuevo para el taller. Así que vamos a ir al laboratorio uno aquí, generar un espacio de trabajo NX vacío para una empresa ficticia llamada BoardGameHorde. Y lo vamos a llamar BG-Horde. Bien. Así que voy a ejecutar NPX create NX workspace. Y lo vamos a llamar BG-Horde. Bien. Déjame hacer esto a pantalla completa para que podamos leerlo.

4. Introducción a NX y Plugins

Short description:

Para nuestra masterclass, utilizaremos el repositorio de modelo integrado, que permite tener múltiples aplicaciones en el mismo repositorio. Los plugins añaden otra capa encima del núcleo de NX, gestionando el sistema de construcción y proporcionando generadores de código. Puedes ejecutar NX list para ver los plugins instalados y añadir nuevos con NPM o Yarn. Los generadores se pueden ejecutar con NX generates o NX console, y puedes crear generadores personalizados específicos para tu organización. En el laboratorio dos del paso dos, crearemos una aplicación de API de Node bajo apps.

Um, vale. ¿Sabes qué? Tengo una versión antigua de create NX workspace. Así que voy a hacerlo en la última versión aquí. Ahí vamos. Esto es lo que deberías ver. Um, entonces, um, te da algunas opciones aquí para elegir entre un paquete basado, um, es, uh, la configuración donde tienes, um, básicamente estás gestionando, uh, tus paquetes con archivos package.json. Y, um, es más libre y básicamente te permite configurar tu propio sistema de construcción de la forma que quieras y NX se aparta de tu camino, a menos que hagas lo que quieras. Um, para nuestro, para nuestro, um, masterclass aquí, vamos a utilizar el integrado. Um, tiene una estructura de configuración con apps y libs, y es más, um, uh, es la, la, la idea con un repositorio integrado es que, que, que, que compras en todo el ecosistema de NX y usas, estás usando plugins para gestionar tu, tu sistema de construcción y tu sistema de linting. Um, y luego, um, y está configurado para que puedas tener múltiples aplicaciones en el mismo repositorio, um, el, el, el, el, el, tú las últimas tres opciones, independiente react, Angular, sin profundidad. Um, estas son opciones donde, donde, donde, donde tienes, uh, donde tienes básicamente una aplicación en tu repositorio y luego múltiples, múltiples bibliotecas que son utilizadas por esa aplicación. Um, y así con la configuración independiente, tienes una aplicación en la raíz de tu repositorio y luego, y luego bibliotecas, um, al lado de ella. Um, pero para, para nuestro, um, masterclass, vamos a utilizar el integrado modelo de repositorio, y luego hay varias otras opciones de aplicaciones aquí. Entonces, apps es, uh, básicamente, uh, una configuración básica, um, react, Angular, todas estas opciones aquí abajo. Configuran, um, una aplicación para ti, pero vamos a, vamos a empezar con nada y luego añadir lo que queramos aquí. Um, veamos, habilitamos el almacenamiento en caché. Vamos a decir que no por ahora. Más adelante, lo añadiremos. Muy bien. Oh, falló porque ya tengo esa carpeta. Así que vamos a eliminar esa carpeta. Integrado. Uh, queremos apps y no a eso. Genial. Um, entonces, um, si eres nuevo en NX, puedes seguir este tutorial, pero, uh, no lo haremos ahora mismo. Y déjame cambiar a una ventana separada. Sí. Ventana de code. Um, veamos. ¿Es lo suficientemente grande esta fuente? Déjame probar eso. Vale. Vale. Um, esto es lo que genera. Tienes una carpeta de apps y libs. Um, tienes NX.JSON, en lo que profundizaremos un poco más tarde. Y en tu package.json, solo tienes NX y neural workspace. Vale. Um, vale. Así que esa es solo la configuración inicial. Ahora déjame volver a mis, um, mis diapositivas aquí. Y tenemos un poco más, un poco más de explicación que hacer. Vale. Así que estos primeros laboratorios tienen muchas, muchas diapositivas que los acompañan, pero más adelante haremos más trabajo práctico aquí. Vale. Así que NX, el núcleo de NX, um, gestiona, uh, tu como el almacenamiento en caché y el gráfico de dependencias y cómo esos, um, esos proyectos dependen entre sí. Uh, ¿qué hacen los plugins? Los plugins añaden otra capa encima de eso, son, son opcionales, um, pero pueden gestionar tu sistema de construcción por ti. Ayudan a gestionar, um, automáticamente, uh, la actualización de las cosas y te proporcionan algunos generadores de código para automatizar algunos de los procesos de desarrollo repetitivos. Así que para ver qué plugins tienes y qué plugins están disponibles para ti, puedes ejecutar NX list, y eso mostrará todos los plugins que están instalados y también una gran cantidad de plugins de la comunidad y plugins oficiales de NX que puedes añadir si quieres. Um, para añadir un plugin, simplemente lo instalas con NPM o con Yarn y luego, um, y luego estará disponible para ti. Um, uh, así que para los generadores, medics no es la palabra correcta aquí, pero para los generadores, puedes ejecutar NX generates. Uh, y luego le das el nombre del plugin y luego dos puntos y luego el nombre del generador y luego cualquier opción que tengas. Así que para el plugin de Angular, haces NXG generate, um, at NARL/ Angular y luego el nombre del generador es app para aplicación y luego el nombre de la aplicación, um, como una de las opciones aquí. Um, también puedes ejecutar generadores usando NX console, que es un complemento de VS code. También hay un NX console para intelliJ. Um, creo que incluso tienen una versión de VIM. Um, VIM no es tan completo en esto porque obviamente VIM no tiene UI, pero hay características de tipo IntelliSense que, que vienen con VIM. Um, así que hay, uh, hay generación de código para, um, ya sabes, un montón de diferentes frameworks para, um, para backend frameworks como, como node y nest y next. Um, y para tooling como TS lint y prettier y, uh, herramientas de testing como protractor y cypress. Um, también puedes crear tus propios generadores, um, personalizados. Haces un plugin dentro de tu repositorio y luego configuras generadores que son específicos para tu organización. Puedes añadir a los generadores proporcionados por NX desde un plugin, o puedes, um, construir tus propios generadores desde cero diciendo, Hola, crea este archivo y, y mueve este code de esta manera. Um, y en lugar de tener una lista de tareas pendientes en un archivo README que tiene 10 pasos, simplemente tienes un generador que dice, okay, introduce el nombre del nuevo componente que estás creando y, o la nueva ruta que estás creando. Y luego todo se configura de la forma en que se supone que debe estar. Muy bien. Um, no es una aplicación de Angular, pero está bien. Así que en el paso dos del laboratorio dos, vamos a hacer una, una API de Node aquí. Así que cuando termine, la estructura de archivos se verá así. Tendremos una aplicación de API debajo de apps. Muy bien. Así que hagamos, veamos si tengo suficiente espacio en pantalla para hacer esto lado a lado. Así que si ejecuto NX --version, uh, ¿qué está pasando aquí? Déjame ejecutar npm install. Veamos qué pasa aquí bamboo. Vale. Vale. Uh, la última versión de node 18 debería funcionar, pero estoy, estoy teniendo problemas con node 18 en este momento. Déjame intentar, um, déjame intentar 16. O podría ser mi, um, podría ser mi máquina que está teniendo problemas extraños. Vamos a intentarlo. No. Vamos a intentarlo aquí. No existe el archivo o directorio. Vale. Estaba haciendo esto ayer. Así que esta es la maldición de la demostración. Todo falla cuando ejecutas la demostración. Déjame intentar reiniciar la terminal. Vale, ahí vamos. Bien. Muy bien.

5. Creando una aplicación Node con NX y Plugins

Short description:

Algo estaba raro con mi terminal, pero ahora está mejor. Podemos usar cualquier versión de Node que queramos. Los generadores personalizados aparecen en la consola NX. Podemos añadir plugins usando el comando NX list. Añadimos el plugin node y Express. Usamos el plugin narwhal-node para generar una aplicación node llamada API. Actualizamos el archivo main.ts y añadimos endpoints. Para servir la aplicación, podemos usar el comando NxServe. Arreglamos un error añadiendo otro archivo. La API está funcionando y hemos confirmado nuestros cambios. Creamos una nueva aplicación rápidamente sin preocuparnos por los ajustes de configuración.

Algo estaba raro con mi terminal, pero ahora está mejor. Estoy usando Node 18, pero puedes usar la versión que quieras.

Sí, buena pregunta. Entonces Naya Kunin pregunta, ¿aparecen los generadores personalizados en la console NX? Y la respuesta es sí. console NX. Así que llegaremos a esto un poco más tarde. Pero entonces, haces clic en generar aquí. Y esto revisa tu repositorio y encuentra todos los generadores. Así que en este caso, solo tenemos nuestro espacio de trabajo instalado. Más tarde, cuando añadamos otras cosas, habrá otras cosas en esta lista. Y si añades tu propio generador personalizado, también aparecerá en esta lista. Ya sabes, cualquier opción que configures para tu generador, aparecerá aquí como campos que puedes rellenar y luego haces clic en ejecutar y aparece. Sí. Vale, genial. Muy bien, entonces. NPX next hacemos esto. Vale, entonces hagamos una lista de NX para ver qué plugins tenemos, y esto genera un montón de code aquí. Así que voy a hacer una lista de NX. ¿Cuál es el gato o es? Configuraciones No. Una lista de NX menos. Tubo a menos. Ahí vamos, así que esto es solo la parte superior aquí, así que te muestra lo que está instalado? Solo NX está instalado, y entonces tenemos todos estos plugins disponibles para nosotros. Así que estos son los plugins oficiales de NX. Y luego hay una lista completa de plugins de la community, con una breve descripción de cada uno de ellos. Y hay muchos aquí. Así que lo que queremos añadir es el plugin node, así que haremos NPMI-D, narwhal-node, y también añadiremos Express. Porque usaremos Express. Así que estos son los pasos tres y cuatro aquí. Así que ahora vamos a entrar en el paso cinco, y usaremos el plugin narwhal-node para generar una aplicación node llamada API. Así que vamos a usar esa sintaxis de generador, nxg en narwhal-node, y luego dos puntos, y luego el generador que vamos a usar se llama app o aplicación, y luego le damos un nombre de API. Así que si quisiéramos usar el NxConsole para esto, así es como sería la línea de comandos. Así que puedo usar NxConsole aquí y ejecutar generar, y así que ahora en lugar de tener solo narwhal workspace, también tenemos narwhal-node, y las dependencias narwhal-node, el linter y JavaScript. Así que narwhal-node crearía una aplicación aquí, y entonces hay un montón de opciones de las que podemos elegir, todo lo que queremos ahora es poner el nombre a API. Y hace una ejecución en seco de esto. Así que hagamos clic en ejecutar aquí, y crea un montón de archivos, actualiza nuestro package.json y actualiza NX, así que veamos los cambios que hizo. Así que en package.json se actualizó, solo formateó eso supongo, añadió algunas dependencias de desarrollo para configurar node para nosotros, añadió Axios y TSLib, añadió ESLint para linting, algunos Prettier para formatear Jest, así que todos estos se configuraron para nosotros crearon una aplicación API con algunas opciones de configuración y una aplicación de extremo a extremo para probar, para hacer pruebas de extremo a extremo en esta API de node. Vale. main.ts es una especie de nuestro punto de entrada aquí. Y entonces project.json aquí es la configuración que controla cómo se ve la construcción y cómo se ve el servicio y lint y test. Y así podemos ver aquí en la console NX aquí, si miramos bajo API aquí, podemos ejecutar build, serve, lint, y test. Así que si ejecutamos build aquí, lo construye y si ejecutamos serve, eso lo lanza en modo de lavado. Y podemos lint y testearlo también. Déjame volver al laboratorio aquí. Muy bien, entonces vamos a actualizar el archivo main.ts para añadir algunos endpoints aquí. Así que realmente no estamos haciendo, esto no es una masterclass de Node. Así que solo vamos a copiar y pegar el code aquí. Así que esto está usando express y configurando eso para nosotros. Y aquí lo hemos hecho.

Vale, así que ahora para servir la aplicación, podemos ejecutar. Así que podemos usar el NxConsole o simplemente podemos ejecutar NxServe API. Oh. Vale. Hay un error en el code que copié. Vale. Main.ts. Creo. Hay otro archivo que necesita ser importado. Sí, hay otro archivo que necesito añadir. Quiero ver dónde lo añadí. Aquí está, este. Games.repository.ts. Así que debajo de esto, necesito hacer una nueva carpeta, app, y un nuevo archivo, games.repository. Sí. Pegar eso. Y guardarlo. Y luego volveré a ejecutar la búsqueda. Vale, así que ahora eso está bien. Ahora si vamos a localhost333 api, slash games. Lo siento, déjame mover esto aquí. Este es el JSON que esperamos ver para la API. Muy bien, así que esta es la emoción del desarrollo de backend. Ves un JSON y estás feliz. Pero los desarrolladores de front-end estarán muy contentos de ver ese JSON pasando. Genial, así que volveremos. Vale, así que eso está funcionando. Y entonces vamos a confirmar nuestros cambios. Así que llamamos a esto laboratorio dos. Y eso está funcionando. Vale, así que, lo que hicimos aquí es que creamos una nueva aplicación completa. Y nos llevó, ya sabes, muy poco tiempo. ¿Puedo, puedo arrastrar esto? Ahí vamos. Nos llevó muy poco tiempo poner eso en marcha. Así que no tuvimos que preocuparnos por lo que sea que esté aquí. No tuvimos que preocuparnos por configurar ts-config o cualquiera de esas cosas. Y, ya sabes, podríamos poner en marcha cinco aplicaciones más en otros cinco minutos si quisiéramos. Así que nos preocupamos por el contenido de nuestro code en lugar de por todas las configuraciones. Muy bien, entonces pasemos a la siguiente diapositiva. ¿Preguntas rápidas sobre eso? Déjame mirar, mirar en Discord. Muy bien, no veo preguntas.

6. Entendiendo los Ejecutores en project.json

Short description:

Hablemos de los ejecutores en el contexto del archivo project.json. Cada proyecto tiene su propio archivo project.json donde se definen los objetivos de construcción, servicio, lint y prueba. Los ejecutores se definen para cada objetivo, y puedes cambiarlos fácilmente para diferentes tareas. Para ejecutar un ejecutor, puedes usar nx run o nx console. En el laboratorio tres, construimos la aplicación usando nx build API y exploramos opciones en nx console. El objetivo de servicio utiliza el objetivo de construcción, y puedes modificar la configuración en el archivo project.json. Así es como puedes establecer diferentes banderas y configuraciones para tu ejecutor.

Así que eso está bien. ¿Vemos que todavía tenemos 32 personas? Así que tenemos, sí, aproximadamente el mismo número. Genial, genial. Bien, volveremos a Keynote aquí. Bien, hablemos de los ejecutores. Así que brevemente te mostré el archivo project.json. Así que cada proyecto dentro de tu repositorio tendrá un archivo project.json, así que, esta diapositiva es incorrecta, pero esta estructura es correcta. Básicamente debajo de tus proyectos, vas a definir construir, servir, lint y test, o cualquier otro nombre que quieras. Así que si tienes alguna generación de documentation, podrías tener un objetivo de documentación. Así que cada objetivo de prueba lo tiene, tiene un ejecutor definido para él. Así que si es un plugin, entonces tiene, ya sabes, Narwal Jest, y luego el nombre del ejecutor. Así que Narwal Jest es el nombre del plugin, y luego dos puntos, el nombre del ejecutor en este caso, que es simplemente Jest. Así que tenemos, déjame mostrar rápidamente... Así que en nuestro caso, tenemos nuestra construcción, y luego el ejecutor. Así que Narwal esbuild, así que está usando esbuild, y luego el ejecutor esbuild. Si quisieras, podrías usar, hay un, veamos, creo que hay NarwalJSTSC. Así que si todo lo que quieres hacer es compilar TypeScript en JavaScript, podrías ejecutar el TSC, o si quisieras cambiar a SWC, podrías hacer eso, y luego hay opciones para cada uno de esos. Así que las opciones obviamente cambiarán para cada ejecutor para configurarlos de diferentes maneras. Estos, en este momento, son las opciones para ES build. Pero puedes cambiar bastante fácilmente qué ejecutor estás usando para hacer cosas como construir, o servir, o testing, o lo que sea. Así que si volvemos a aquí. Bien, eso es un ejecutor.

7. Ejecutando Ejecutores y Configurando Objetivos

Short description:

Para ejecutar un ejecutor, use nx run o nx console con el nombre del proyecto y el objetivo. También puede usar nx serve o nx build con la notación abreviada. Las opciones se pueden especificar después del nombre del objetivo. La consola nx proporciona opciones prellenadas desde el archivo project.json. Ejecutar nx build API agrupa todos los archivos TS en un solo archivo JS. La opción de agrupación se puede establecer en project.json o a través de la línea de comandos. El serveTarget utiliza el buildTarget para ejecutar la aplicación después de construirla. Se pueden establecer diferentes configuraciones para los objetivos de construcción y servicio.

Entonces, para ejecutar un ejecutor, puedes hacer nx run, y luego el nombre del proyecto que es API, y luego el objetivo que será serve o build, y luego las opciones que vengan después. Así como nx run MyAppServe, o para la abreviatura podrías tomar el nombre del objetivo y ponerlo al frente. Así que nx serve MyApp, o nx serve API, o nx build API, y luego las opciones vienen después. Así que esto funciona para cualquier nombre de objetivo que tengas y cualquier nombre de aplicación.

Lo mismo, también puedes ejecutarlo con nx console, y te dará todas las opciones como campos rellenables aquí. Bien, probemos eso. Si vamos aquí en el laboratorio tres. Así que tenemos ejecutores. Así que queremos construir la aplicación. Así que si servir la aplicación era nx serve, para servir la aplicación, haz clic aquí. Ahí vamos. Bien, servir la aplicación era nx serve API. Así que para construir la aplicación, haremos nx build API. Como ya lo hemos hecho desde la línea de comandos, voy a intentar hacerlo desde nx console, solo para que lo veas. Así que puedo hacer clic aquí y simplemente hacer clic, como ejecutar aquí, y eso simplemente lo ejecutará sin darme el formulario, pero voy a ir abajo a construir aquí y hacer build API. Y esto me da un montón de opciones aquí. Así que estas ya están prellenadas. Así que estos son los valores que están en el archivo project.json. Así que el archivo main.ts está aquí. Así que eso es lo que está prellenado aquí. Así que me da el valor por defecto que está lleno en el archivo project.json, pero si quieres cambiarlo, puedes cambiarlo aquí y luego ejecutarlo en otro lugar. Parece que, esto parece un error de NxConsole aquí. Interesante. Pero vamos a intentar ejecutar esto. Y entonces lo construyó y lo puso en, en la ruta de salida que definimos aquí. Así que dist apps API. Así que dist apps, dist apps API está aquí. Y así es como, este es nuestro resultado. Bien, veamos. Así que lo construimos. Así que pusimos cosas en la carpeta dist. Miremos bajo los proyectos de apps API en Asan, y tiene una opción ejecutiva que está ahí. Y queremos, queremos cambiar esto para ser, para ser minimizado. Así que para agrupar todo. Así que, en lugar de decir bundle false, digamos bundle true. Y veamos qué hace eso a, a la salida. Así que si ejecuto NX, NX build API de nuevo. Así que ahora si miramos bajo dist aquí, así que ahora en lugar de tener esa carpeta debajo de aquí que tenía el repositorio de juegos, todo está construido en un solo archivo JS. Así que esto tiene, veamos cuál es el tamaño de esto? Oh, no sé, 23,000 líneas de code aquí mientras que si fui a project Json y puse esto en falso, ejecuto esto de nuevo, ejecuto esto de nuevo, aquí este archivo main.js solo tiene 36 líneas de code. Y luego está el repositorio de juegos y eso es todo. Así que y luego hay otras cosas que son como las dependencias que no se agrupan. Así que esa es la diferencia. Así que puedes establecer eso en el archivo project.js Json o también puedes establecerlo en, desde la línea de comandos. Puedes hacer dash-bundle equals true aquí y eso lo agrupará en un solo archivo como este. Bien. Así es como puedes establecer lo que sea, cualquier bandera que quieras en tu, en tu ejecutor. También puedes obtener. Veamos. Bien. Parece que el autocompletado no está funcionando ahora mismo para Nix console. Está bien. No. Bien. Así que miremos. Así que hemos, hemos establecido el bundle en true. Instruye al ejecutor para agrupar todos los archivos TS en un solo archivo JS, lo cual hiciste. Así que el serveTarget utiliza el buildTarget. Así que este build tiene, tiene opciones aquí. Así que cerremos esto. Así que serveTarget aquí abajo tiene un buildTarget de API build. Así que básicamente lo que esto está haciendo es decir, primero construye esta aplicación usando lo que está definido aquí arriba, y luego ejecuta node en, en la salida de eso. Así que eso es todo lo que está haciendo el servicio. Así que si quisieras cambiar esto y hacer, así que puedes tener una versión de desarrollo y una versión de producción. Así que esto solo ejecuta el, el build con la configuración de producción, que está configurada aquí, y luego este serveTarget, sirve con la configuración de desarrollo, ejecuta el, el build para desarrollo y luego ejecuta node en él. Así que si, si quieres establecer el NxBuild API, si quieres establecer la configuración a producción manualmente, puedes hacerlo así, o puedes establecerlo a desarrollo de esta manera. Ve a la izquierda, y de esta manera, tal vez es configurar, lo siento. Creo que tienes que escribir toda la configuración. Ahí vamos. Así que lo ejecutó con desarrollo. Así que la configuración por defecto es desarrollo aquí, y para construir, la configuración por defecto es producción. Así que puedes, puedes cambiar eso, estos nombres son totalmente arbitrarios, así que puedes, puedes establecer estos a cualquier nombre que quieras que sean.

8. Configurando Ajustes y Creando Bibliotecas

Short description:

Puede configurar diferentes tipos de ajustes y sobrescribir opciones en archivos de configuración. Janet pregunta sobre el uso de la versión global o NPX. NX puede usar cualquiera, utilizando automáticamente la versión establecida en package.json. Las bibliotecas están diseñadas para ser utilizadas por aplicaciones u otras bibliotecas, mientras que las aplicaciones pueden ser desplegadas o ejecutadas directamente. NX opera a nivel de biblioteca o aplicación. Dividir el código en bibliotecas permite más almacenamiento en caché e infraestructura. El gráfico de dependencias es a nivel de proyecto. NX puede llamar a los scripts de package.json. Se pide a Get little tech que comparta su pantalla para solucionar problemas. El laboratorio cuatro implica la creación de una biblioteca.

Así es como puedes configurar diferentes tipos de ajustes. Cada opción debajo, debajo de producción es la misma. Todas estas opciones pueden ser sobrescritas en estos archivos de configuración. Lo que esto hace es tomar todo lo que está bajo opciones y mantenerlas iguales excepto por lo que se especifica aquí. Esto simplemente sobrescribe estas ESBuildOptions y establece SourceMap en falso y OutExtensions en lo mismo. Así que, todo lo que hace es sobrescribir SourceMaps para ser falso en lugar de verdadero. Pero si necesitas cambiar algo más, podrías cambiar algo más.

Así que Janet está preguntando si deberías usar la versión global o usar NPX. Me gusta usar solo NX directamente. Si usas NPX-NX, también está bien. NX usará automáticamente la versión que está establecida en tu package.json. Así que si tengo un NX global de... Ahora mismo, 15.9.2 es lo que está instalado localmente. Y estoy seguro de que mi versión global no es esa. Así que si salgo de aquí y hago NX-V, oh, ni siquiera me lo dice. Pero si hago NX-V dentro de bg-hoard, es... Quizás después de hacer NX-V. Así que aquí dentro de bg-hoard es 15.9.2. Si salgo de aquí, NX-V, todavía no le gusta. Bueno, pues... Sí, dice que no puede encontrar la versión global, lo cual es raro porque definitivamente estoy usando NX globalmente. Pero NX simplemente usará lo que se ejecute localmente. Lo que esté allí dentro de esta carpeta. Construir para la línea de comandos. Alguien está llamando... Ah. Bueno, vamos a hacer un... Voy a repasar las diapositivas y luego get little tech. Quizás te pida que compartas tu pantalla mientras la gente trabaja en el Laboratorio 4. Porque tengo curiosidad por saber por qué no te funciona. Así que déjame hacer algunas diapositivas para el Laboratorio 4. Y luego... Hasta ahora, todo lo que hemos hecho es crear una aplicación. Estamos a una hora, bien, estamos bien. Hasta ahora, solo hemos creado una aplicación. A continuación, vamos a crear una biblioteca. Así que la diferencia entre una aplicación y una biblioteca es que las bibliotecas están diseñadas para ser utilizadas por aplicaciones u otras bibliotecas. No están diseñadas para ser desplegadas. Podrían ser publicadas en npm para ser utilizadas fuera del repositorio, pero aparte de eso, aparte de eso, se espera que se utilice el code, en lugar de ser desplegado directamente. Mientras que las aplicaciones son, puedes desplegarlas para alojarlas en algún lugar o puedes ejecutarlas directamente. Eso es lo que es una aplicación. Así que típicamente puedes tener bibliotecas que son características como una ruta en una aplicación de front end o están enfocadas en UI o en data o simplemente son bibliotecas de utilidad de nivel inferior. Puedes hacer las bibliotecas tan granulares como quieras. Pero NX opera a nivel de biblioteca o a nivel de aplicación para cada proyecto. Si quieres usar más de la funcionalidad de almacenamiento en caché de NX entonces ayuda a dividir las cosas en más bibliotecas. Así que las bibliotecas pueden tener básicamente la estructura de directorios que quieras. Puedes tener una carpeta, puedes agruparlas dentro de carpetas. No tienen que estar dentro de la carpeta libs pero eso es lo que es por defecto para esta configuración de la masterclass. Puedes tenerlas en el nivel raíz si quieres o puedes renombrar la carpeta libs a algo más. Puedes llamarlas paquetes o bibliotecas o cualquier nombre que quieras allí. Típicamente, vemos para grandes organizaciones, para cada aplicación típicamente tienes una carpeta dentro de la carpeta libs. Así que las bibliotecas que son específicas para esa aplicación irían en esa carpeta. Así que tendrías como una carpeta libs slash API y luego una lib slash, no sé, front end o libs slash store si tuvieras una aplicación de tienda, como una aplicación de front end. Y luego tendrías una carpeta libs compartida en la que vivirían las bibliotecas que podrían ser utilizadas en múltiples aplicaciones. Así que básicamente toda esa estructura depende bastante de ti lo que tenga sentido para tu base de código. En términos generales, cuanto más divides el code en nuevas bibliotecas, más te ayudará el almacenamiento en caché y más te ayudará la infraestructura de índices. Pero hay un costo para crear una nueva biblioteca. Es otro, el code está siendo separado en diferentes ubicaciones. Así que tienes que saber, quieres agrupar el code juntos que tiene sentido estar juntos. Pero si es, los mismos pros y contras que dividir el code en carpetas separadas o dividir el code en archivos separados o componentes separados. Es lo mismo con las bibliotecas. Definitivamente puedes pasarte de la raya en un lado o en el otro. Solo, y siempre puedes cambiar de nuevo. Si tienes una biblioteca que es demasiado grande, puedes dividirla. Si tienes demasiadas bibliotecas, puedes combinarlas de nuevo. Así que tu gráfico de dependencias es a nivel de proyecto. Así que cada biblioteca o aplicación es un nodo en el gráfico de dependencias. Y eso es lo que tenemos para las bibliotecas. Bueno, déjame volver y responder algunas de estas preguntas en Discord aquí. Así que vi que Toon está preguntando, ¿puede NX llamar a los scripts de package.json? Sí, sí puede. Así que esta masterclass te está mostrando un repositorio de estilo integrado que está usando Project JSON. Pero si tuvieras, déjame mostrarte rápido aquí. Veamos, archivo, package.json y default package.json. Eso está bien. Creo que quiero llamar a esto. Creo que se confundirá si el nombre no coincide. Así que scripts. Así que si... Así que Project JSON es opcional. Puedes tener solo un package.json en lugar de un project.json, y así que veamos, o podrías tener ambos. Así que digamos, llamemos a esto hola y diremos echo hola mundo. Hagamos hola desde package.json. Así que si ejecuto nx hola, porque hola es el nombre del script aquí, nx hola y luego API es el nombre del proyecto. Ejecuta hola desde package.json. Así que lo que pongas aquí, lo ejecutará para ti. Así que sí. Y luego había otra pregunta. Y luego sí get little tech. ¿Te gustaría compartir tu pantalla y mostrarnos qué pasa con tu VS code? Para todos los demás, siéntanse libres de empezar con el laboratorio, laboratorio cuatro, creo que es el siguiente. Sí, laboratorio cuatro, donde estamos creando un...

9. Masterclass de NX: Migraciones de Node y Pasos del Laboratorio

Short description:

En el laboratorio cuatro, profundizamos en las migraciones y la actualización de dependencias. Añadimos una versión antigua de Node de la masterclass de NX y luego migramos a la versión más reciente. El archivo migrations.json contiene los generadores de código necesarios para cada paso del laboratorio. Al ejecutar las migraciones, podemos completar la configuración para todos los laboratorios hasta un paso específico. Sin embargo, puede haber algunos problemas con el proceso de migración que necesitan ser resueltos. También podemos ejecutar pasos de laboratorio específicos comentando el código innecesario en el archivo migrations.json.

Oh, el laboratorio cuatro es en realidad, si te quedas atascado, así que seguiremos con esto. Vale, así que has hecho clic en ejecutar. ¿Qué pasa cuando haces clic en ejecutar? No aparece nada. Sí, exactamente. Parece que no funciona, pero tal vez no. Intenta hacer clic en construir en la parte inferior bajo generar y ejecutar objetivo. Vale, haz clic en super node, y luego haz clic en ejecutar aquí. ¿Funciona eso? No funciona, pero en realidad se ejecutó desde el terminal. Vale. No lo sé. Sí. Puedo averiguarlo más tarde. Sí, vale.

Y Jannik está preguntando, si estoy construyendo una aplicación de front-end, ¿cuál es la mejor práctica para estructurar la adición de nuevas características? Sí, por lo general, si estás añadiendo una página o parte de una página, quieres que sea una biblioteca, no una aplicación. Y luego usarías esa biblioteca dentro de la aplicación. Así que permíteme repasar aquí el Laboratorio 4. El Laboratorio 4 está profundizando en las migraciones. Y también, si necesitas saltar a un particular, si te quedas atascado en una sección particular de la arquitectura, de la masterclass, puedes saltar a ese paso. Así que una de las cosas que los plugins de NX te dan es la capacidad de actualizar automáticamente tu código, actualizar tus dependencias. Y luego actualizar tu código para tener en cuenta los cambios que podrían haber ocurrido. Así que lo que vamos a hacer es que vamos a ejecutar, vamos a añadir un Node de la masterclass de NX, una versión antigua de él. Y luego vamos a ejecutar, sí, y luego vamos a intentar migrar. Así que hagamos esto. Npmi-d. En realidad en narwhal en lugar de la rama. Vale, así que esta es una versión antigua del Node de la masterclass de NX. Así que esto podría ser cualquier plugin que tengamos. Así que ese narwhal, en narwhal/nodo o en narwhal/react o cualquier plugin que estés usando. Permíteme eliminar este paquete. Jason aquí. Y vale, así que hemos añadido esto. Vale, y luego vamos a hacer un commit de nuestros cambios aquí, sólo para asegurarnos de que tenemos una configuración limpia aquí. Y entonces vamos a migrar a la última versión del Node de la masterclass de NX. Así que, NX tiene el comando de migración de NX en narwhal nx. Así que si sólo haces NX migrar último, eso migrará NX en sí mismo y cualquier plugin que esté instalado. Así que si ejecuto eso, eso hará básicamente todo. Y entonces veamos qué actualizó. Así que todas estas ya están actualizadas. Y todo lo que hice es formatearlo. Veamos, el Node de la masterclass de NX está ahí. Así que hagamos NX migrar narwhal Node de la masterclass de NX. Eso debería encontrar la versión 1.0.0. Comprobemos eso. Veamos si lo subo manualmente. Vale, ahí está, así que lo encontró. Vale, creo que parte del problema ahí por qué eso no estaba funcionando como esperaba es cuando configuré la masterclass, publiqué 1.0 primero y luego 0.0.1 más tarde. Normalmente sólo dices NxMigrate y encontrará la última versión. Así que lo que hizo es que actualizó, ¿por qué eso no se actualizó entonces? Vale, así que normalmente lo que hará es que actualizará esto. Oh, ya veo, sí lo actualizó. Sólo que no, ahí está. Bien, hizo lo que se suponía que debía hacer. Así que actualizó esto a 1.0 y también creó este archivo migrations.json. Y así que estos son todos los generadores de código que se necesitan para moverse hasta esa versión, esa siguiente versión. Y así que estamos usando una versión de Frankenstein de esto. Así que normalmente esto sería como modificar tus códigos para hacer cualquier cambio, arreglar cualquier cambio que básicamente para esa dependencia. Pero en nuestro caso, lo que esto está haciendo es que cada uno de estos generadores está completando el paso para cada laboratorio. Así que esto está completando el laboratorio uno, esto está completando el laboratorio dos, tres. El laboratorio cuatro es lo que estamos haciendo ahora, así que no hay nada que hacer allí. Y luego esto te llevará hasta el laboratorio tres y cinco y todo el camino hasta el laboratorio 13 aquí. Así que si ejecutáramos todo esto, puedes ejecutar index migrate dash dash run migrations. Así que eso ejecuta todos estos pasos de configuración. Oh no. Así que eso no, tiene algo de código antiguo allí. ¿Por qué tiene código antiguo allí? No tengo, Depuración en vivo. No debería necesitar eso. No hay Angular involucrado allí. O no. ¿Qué pasa si tuviera dos? Migraciones para eso. Oh, sólo ejecuta npm i. Mm. Vale, um. Hay algo mal con mi migración, así que sólo voy a ejecutar. Sólo instalé eso. No hay razón para que eso esté allí, um, pero sólo para avanzar, lo ejecutaremos. Vale. Sí. Uh, vale, así que esto se ejecutó a través de todos los pasos hasta el laboratorio ocho donde se detuvo. Me quedé atascado en algo, pero puedes ver que aquí hizo un montón de cambios, añadiendo algunas aplicaciones y um añadiendo algunas bibliotecas aquí. Así que esto es todo lo que aún no hemos llegado. Um, así que si quieres sólo ejecutar hasta hasta el laboratorio tres aquí, sólo voy a comentar eso aunque no es un json válido. Um, lo ejecutaré de nuevo. Así que esto sólo ejecutará el laboratorio uno, dos y tres y nos llevará de vuelta al lugar donde se suponía que debía estar. Mmm. Vale. Déjame Eliminar esos. Muy bien. La consola de Nx tiene un estancamiento. Voy a ejecutar el comando de ejecución. Nx G rm cli bansheet e.

10. Creando una Biblioteca con NARL JS

Short description:

Vamos a crear una nueva biblioteca llamada off utilizando el plugin NARL JS. Las bibliotecas y las aplicaciones son similares en NX, pero las bibliotecas suelen estar en la parte superior del gráfico de dependencias. Pueden tener objetivos de servir, construir y desplegar al igual que las aplicaciones. Para generar la biblioteca, utiliza el comando de generación con la bandera NXG y especifica el plugin NARL JS. Esto te permite crear lógica reutilizable, como la autenticación, y utilizarla en tus aplicaciones. NX ayuda a mantener tu repositorio actualizado con scripts de migración que se pueden ejecutar para actualizar tu base de código cuando ocurren cambios importantes. Es importante hacer commit de tus cambios antes de ejecutar los generadores y revisar los cambios realizados. Ahora, pasemos al siguiente laboratorio donde crearemos la biblioteca y la utilizaremos en nuestra aplicación.

Elimina eso. y elimina la biblioteca de interfaz mootle. Y. Y estamos de vuelta. Vale. Así que esto nos prepara hasta el laboratorio tres. Si queremos ir al laboratorio cinco, podemos comentar esto. Así que podemos hacerlo de esta manera o hay un generador que viene con el, um, con el. Masterclass. Um, plugin aquí y siguiente masterclass. Y siguiente masterclass, no para completar laboratorios. Y quiero completar el laboratorio, um, cinco. Así que si completo el laboratorio cinco, puedes hacer un rango o puedes hacer completamente el laboratorio voy a ejecutar eso. Y lo que hace es que actualiza mi archivo de migraciones como Jason para tener sólo completando el laboratorio cinco aquí. Y luego puedo ejecutar un ex run migrations aquí, ejecutar eso, y eso completará sólo el laboratorio. Cinco. Así que la idea aquí es que tu, um, esto te ayuda a mantener tu repositorio actualizado. Um, básicamente el, el mantenedor de la biblioteca puede escribir estos scripts de migración. Así que cuando saben que están haciendo un cambio importante, pueden decir aquí, cualquiera que esté usando esta biblioteca, ejecuta este script de migración. Y, um, y sabes, puedes actualizar sin, sin necesidad de conocer, um, todos los detalles técnicos de los diferentes, um, cambios de API que están ocurriendo. Um, así que esto creó una nueva, una nueva, uh, biblioteca que vamos a hacer en el próximo laboratorio. Vale. Déjame volver a aquí. Um, empieza generando una versión, luego cambia algunas cosas a mi gusto y luego actualiza. Así que para nuestro caso, um, el, um, así que para este escenario particular, este, este nodo de masterclass NX, um, estos scripts de migraciones, um, el, el primero, um, completar el laboratorio uno va a resetear todo, borrar todo tu code básicamente, y luego, um, Y luego empezar desde cero. Y luego empezar desde cero. Um, así que si tienes code que no quieres actualizar, uh, no quieres que sea, sabes, borrado, entonces no ejecutes estos scripts. Um, o podrías intentar simplemente ejecutando el, como el, el siguiente laboratorio. Y eso sólo intentará añadir. Um, code. Um, y siempre, si no te gusta lo que un generador ha hecho, asegúrate de hacer commit antes de ejecutarlo. Y entonces siempre puedes revertirlo aquí con tu, tu historial de git. Eso siempre es una buena práctica cuando estás ejecutando un generador, asegúrate de que tienes un historial limpio de git y luego ves lo que hizo y luego puedes deshacerlo si necesitas, um, vale. Vale, así que sigamos adelante. Haremos un laboratorio más y luego tomaremos un descanso. Piénsalo, quizás un descanso de 10 minutos. Um, vale. Así que, hagamos el, um, Veamos, ¿tenemos eso para. Vale. Me pregunto si hay, no. Vale. Parece que estamos haciendo diapositivas. Bien. Muy bien. Hemos terminado con las diapositivas. Hagamos el siguiente laboratorio. Vale. Hasta ahora sólo hemos hecho aplicaciones. Um, a continuación vamos a hacer una biblioteca. Um, digamos que tenemos una aplicación API. Tenemos algo de authentication que necesitamos hacer, y queremos que eso sea una lógica reutilizable. Um, así que esto, esta autenticación. Cualquier lógica de authentication que estemos haciendo, um, vamos a mantenerla dentro de una biblioteca. Y, um, y luego vamos a, um, Uh, luego vamos a usar ese code en la aplicación. Um, así que, um, así que este es un buen momento para responder a la pregunta de Jenick. Um, el, um, ¿diferencia NX entre vidas y aplicaciones? Um, la única diferencia, um, Básicamente básicamente, no. Um, básicamente son, son la misma cosa. Um, la principal diferencia es para, para los usuarios de tu base de code. Um, es útil poder ver esto, esto es como el punto de entrada para nuestro, um, base de code. Como, si quieres entender desde un alto nivel, qué está pasando en esta base de code, miras en la carpeta de aplicaciones y ves, sabes, todo lo que puede ser desplegado. Um, y eso es como una comprensión de alto nivel de lo que está pasando. Um, Puedes hacer, um, bibliotecas que tienen un objetivo de servir. Um, puedes hacer, um, obviamente puedes tener un objetivo de construcción en las bibliotecas. Incluso puedes tener un objetivo de despliegue en, en la biblioteca para que puedas hacer todo lo que puedes hacer con una aplicación. También puedes hacerlo con bibliotecas. Um, pero normalmente, um, las aplicaciones están en la, en la parte superior de tu, yo ni siquiera he mostrado esto todavía. Déjame, déjame mostrar el rasguño de Nx aquí. Um, Normalmente las bibliotecas están en la parte superior de tu. Um, de tu, tu gráfico de dependencias. Vamos a alejarnos un poco. Um, así que la API está aquí en la parte superior y luego la biblioteca API auth que vamos a crear, um, está en la parte inferior. Uh, estas cosas las haremos más tarde. Um, pero, um, el, sabes, incluso en el, en el gráfico aquí, ellos, ellos tienen el mismo como símbolo. Um, así que básicamente, puedes tratarlos como la misma cosa. Sí, básicamente las aplicaciones tienen puntos de entrada. Um. Vale. Muy bien. Así que sigamos adelante. Um, para hacer una biblioteca de JavaScript simple, vamos a usar el paquete NARL JS, el plugin NARL JS. Y, uh, eso ya estaba instalado porque instalamos el, el plugin NARL node y NARL node depende de NARL JS. Así que ya deberías tener NARL JS disponible para ti. Um, déjame deshacerme de estos. Gracias por las cosas. Esas no necesitan estar ahí. Um, y el, así que vamos a hacer una nueva biblioteca y la vamos a llamar off. Para generarla, vamos a usar el, el comando de generación de nuevo. Vale. Con esa bandera NXG, um, así que el plugin que vamos a usar es NARL JS. Así que para saber qué, um, qué plugin usar, um, Así que voy a ejecutar hacer generar aquí.

11. Creando y Usando Bibliotecas

Short description:

Hay dos tipos de bibliotecas disponibles: JS y node. JS es para JavaScript de bajo nivel que se puede usar en un contexto de nodo o de front-end, mientras que node es específico para aplicaciones de nodo. Para crear una biblioteca de JavaScript, utiliza el complemento NXG con el generador de bibliotecas. Si necesitas eliminar una biblioteca, utiliza el generador de eliminación o omite completamente el complemento. La biblioteca API auth se crea y se copia en la carpeta API. Se crea el punto de autenticación en el archivo main.ts. Reinicia el servidor TypeScript si encuentras errores después de actualizar el archivo tsconfig.base. El gráfico del proyecto muestra la dependencia entre la aplicación API y la biblioteca API auth. NXGraph es una herramienta útil para rastrear las dependencias en repositorios más grandes. Haz commit de los cambios como laboratorio cinco y continúa con los laboratorios seis y siete.

Así que hay dos tipos diferentes de bibliotecas disponibles para nosotros. Pueden ser JS o node. Um, JS es para, ya sabes, JavaScript de bajo nivel que se puede usar en un contexto de nodo o en un contexto de front-end. Um, donde, si quieres usar node para cosas que son específicas de node. Entonces, las cosas de node pueden usar JavaScript react, pueden usar JavaScript, angular para usar JavaScript. Cualquier cosa que esté escrita con JavaScript para usar una biblioteca de JavaScript plano, mientras que node sería específico para node.

Um, así que para hacer una biblioteca de JavaScript, usaríamos, um, NXG en narwhals, eso es JS y lo llamaremos. Vamos a usar el generador de bibliotecas. Y vamos a llamar a la biblioteca, uh, off. Así que voy a escribir aquí. Um, ¿qué corredor de pruebas unitarias quieres usar? Um, supongo que usaremos Jest, pero puedes usar V tests si quieres. Um, ¿qué empaquetador dirías, supongo, TSC? Um, pero puedes jugar y usar lo que quieras ahí. Um, Uh, ¿por qué tan serio? Mencionaste que tu archivo migration.json no se ha creado. Uh, eso significa que necesitas ejecutar. Necesitas ejecutar el comando NX migrate. Este NX migrate. Um, puedes decir migrar latest o migrar NX migrate en Narwal NX masterclass node, um, en. 1.0.0 eso creará tu archivo migrations.json. De acuerdo. Así que hemos creado la carpeta off. Oh, sabes qué? Cometí un error aquí. De hecho, ya lo hemos creado. Um, pero queremos que esté debajo de la carpeta libs API. Así que en realidad, voy a mostrarte cómo eliminar una biblioteca después de haberla creado. Así que podrías simplemente eliminar esta carpeta, pero el problema con eso es que, um, y X también creó otra entrada aquí. Um, y potencialmente ha modificado algunas otras configuraciones de archivos, um, con esa biblioteca. Así que si solo eliminas la carpeta, tendrás, ya sabes, configuración superflua en otros lugares. Para eliminarla, hay un generador de eliminación en el espacio de trabajo de NARWAL. Um, R.M., puedes hacer R.M. o hacer remove. Um, pero también puedes omitir completamente el complemento. Y si no hay, um, entonces podrías hacer esto, bueno, podrías hacer esto. Lib. Si haces un NXT lib, te permite elegir qué biblioteca quieres. Um, pero como solo hay un generador de eliminación, sabe exactamente cuál quieres. Um, así que si hacemos NXT, uh, lib, um, y queremos establecer la bandera de directorio aquí, establecerla en API y el nombre, qué biblioteca es la que queremos llamar, qué biblioteca es la que queremos llamar para icono. Y el nombre de la bandera de directorio, um, es el que queremos usar para establecer reply. Así que no tienes que volver a escribir el comando. Um, para que se vea realmente como lo mismo, puedes simplemente, ya sabes, el nombre va a ser off. Otra cosa que podrías hacer es hacer, um, API slash off así, y luego sabe que los directorios son API, um, y te pregunta qué tipo de biblioteca quieres. Diré JS y todo esto. Um, y luego ve, oh espera, ya existe. Así que. No necesitamos crearlo. Porque ya lo hice con la migración. Cuando ejecuté los scripts de migración con LabVive completo, ya lo creó para mí. Así que lo dejaremos ahí. Y luego esto se copia en API auth.ts. Te mostraré cómo se ve eso. Esto es lo que se copió. Y luego para usarlo en tu punto de autenticación de API, así que aquí arriba, en api.src.main.ts. Aquí. Entonces este punto de autenticación aquí se crea. Esto tiene un error porque necesitamos actualizar nuestro, necesitamos volver a ejecutar el TypeScript, reiniciar el servidor TypeScript, volver a ejecutar el TypeScript, reiniciar el servidor TypeScript. Cada vez que se actualiza el tsconfig.base, estas rutas se actualizan, el servidor TypeScript, no se da cuenta de que se ha actualizado. Así que tienes que reiniciar el servidor TypeScript. Acabo de hacer un comando chip P y reiniciar, y esto se calló, y luego eso solucionó rápidamente eso. Así es como importa la función doAuth de nuestra biblioteca. Entonces se define aquí en API auth, y se exporta aquí en index.ts, dice que todo lo que está en API auth, lo estoy exportando y diciendo que está disponible pero para ser utilizado. Si comentara esto, entonces esto fallaría porque está diciendo, Hola, no puedo exportar nada. Así que esta es tu API pública para tu biblioteca. De acuerdo, ¿qué sigue? Y luego vamos a lanzar el gráfico del proyecto. Así que hagamos esto. Ejecuté un NX graph. Y aquí tenemos nuestra aplicación API y la biblioteca API auth. Así que esta conexión aquí, dice que esta API depende de API auth debido al contenido de source main.ts. Porque aquí, debido a esta línea de importación, es de donde viene esa línea de dependencia. Esto es muy útil, especialmente en un repositorio más grande donde no sabes por qué se está dibujando una línea de dependencia. Puede ayudarte a rastrear, okay, ¿por qué hay una dependencia en circuito? ¿Por qué esto depende de eso que a su vez depende de sí mismo de nuevo? Puedes averiguar qué archivos están causando que eso suceda. De acuerdo. Así que no cambié ninguno de los archivos JSON del proyecto o no le dije a NX que la API depende de la biblioteca Auth. Todo lo que hice fue escribir mi code. Y si alguien más más adelante viene y elimina esta línea de code, luego ejecutamos NXGraph de nuevo. De acuerdo. Tengo que hacer un reinicio aquí. Así que hay algunos problemas, creo. Y actualicemos esto. Ahí vamos. Y ahora NXC está, oh. Ya no están conectados, porque alguien ha actualizado el code para romper esa línea. Muy bien, así que lo volveremos a poner. Y hagamos commit de esto como laboratorio cinco. Muy bien. Bien. Hemos terminado con los laboratorios uno a cinco. Comenzaremos con el laboratorio seis aquí. Y luego profundizaremos.

12. Creando una CLI de Node y Compartiendo una Biblioteca

Short description:

En el laboratorio seis, añadimos una CLI de node. Creamos una nueva aplicación de node llamada CLI NXG app CLI. En el laboratorio siete, compartimos una biblioteca entre la CLI y la API. Creamos una biblioteca de JavaScript llamada util interface y la importamos en el archivo del repositorio de la API. Los objetos de juegos se les da el tipo de array de juegos. El proceso de construcción se ejecuta sin errores.

Y luego del ocho al trece se centra más en el tipo de architecture estructura del repositorio.

Veamos, Andrix dice, Sí, así que Andrix responderemos a tu pregunta en el laboratorio ocho. Así que llegaremos allí. Bien, así que comencemos en el laboratorio seis aquí. Y la respuesta es sí. Así que en el Laboratorio Seis, vamos a añadir una CLI de node. Básicamente estamos haciendo otra aplicación de node. Mantén las instrucciones a un lado aquí. Así que crea una nueva aplicación de node, llámala CLI NXG app CLI. No estoy especificando el complemento así que debería preguntarme. Oh, sí, así que solo hay una aplicación generada ahora mismo en nuestros complementos. ¿Qué framework quieres usar? Voy a decir ninguno porque solo quiero que sea una CLI. Y así se configura con el nombre CLI. Actualicemos el archivo main.ts con el, aquí, copiándolo. Así que ahora tenemos dos archivos main.ts para que tengamos el de CLI. Actualiza eso. Y así es no está usando ninguna otra biblioteca, así que si volviéramos a ejecutar nx-graph de nuevo, refresca esto, notarás que la CLI no depende de nada más, solo tenemos una aplicación ntn y luego la CLI misma. Vale. Y eso debería ser, vale. Eso no está enfermo. Eso es el laboratorio seis. Genial.

Pasemos al laboratorio. Oh, espera. Nos saltamos. Bien, ese enlace estaba mal. Queremos ir al laboratorio siete, no al ocho. Vale. Laboratorio siete. Vale. Déjame hacer un commit a esto. Eso fue el laboratorio seis. Laboratorio seis muy rápido. Si quisiéramos... Déjame mostrarte rápidamente cómo ejecutar el archivo main.ts. Haríamos nxserve, lo ejecutaría. Así que si hago eso nxserve-cli, oh, vale. Está intentando hacer, intentando hacer una solicitud a localhost 333, pero la API no está funcionando. Así que si, acabo de servir la API, y luego en un terminal separado hago serve-cli. Vale, aquí vamos. Así que lo listó, hizo, hizo una, llamada a la API y luego listó el, el nombre y la descripción aquí. Así que funcionó como queríamos. Parece que el slash end no está funcionando en la console aquí. Así que si, si, está listando todos los juegos aquí. Así que eso está funcionando lo suficientemente bien para una demostración. Pasemos al laboratorio siete aquí. Así que ahora queremos compartir una biblioteca entre dos aplicaciones diferentes. Así que a veces quieres, quieres tener algún tipo de conexión entre, una aplicación de front end y una de backend. Así que la CLI es nuestra, es nuestra front end. Y cuando esa interfaz cambia, queremos que tanto la front end como el backend se aseguren de que están coincidiendo con esa interfaz. Así que vamos a hacer un tipo de TypeScript para definir lo que es un juego. Y tanto la CLI como la API usarán ese tipo de TypeScript. Y de esa manera pueden mantenerse sincronizadas. Así que cada vez que ese contrato cambia, ambas están sincronizadas. Así que de eso se trata este Laboratorio 7. Así que detén el servicio. Así que vamos a hacer una nueva biblioteca de JavaScript, la llamaremos util interface. Y vamos a asegurarnos de pegarla debajo de la carpeta de la API. Luego más tarde la moveremos a otro lugar. Así que hagamos, así que nx genera una biblioteca. La vamos a llamar API util interface. Así que aquí está mi forma abreviada para asegurarme de pegarla debajo de la carpeta de la API aquí. Vale y luego porque no especificé el complemento, me va a preguntar cuál quiero. Así que quiero usar js, no node. Luego no me importa realmente cuál de esos. Así que bajo apps tenemos eso, así que ahora bajo libs tenemos libs api-auth y libs api-util interface. Vale y ahora veamos qué sigue. Vale, así que cuando hago la interfaz de juego aquí, vale mi enlace no es correcto. Source lib api-util interface y luego slash tal vez. No, vale. Tengo que ir a buscarlo. Muestras lab7. Este es el, api-util interface. Si alguien quiere ganar puntos extra, pueden entrar y arreglar los enlaces rotos en mi code aquí. Vale, así que actualiza eso. Y así tenemos el juego siendo exportado para api-util interface. Aquí. Vale, así que hicimos eso. Queremos importarlo en el archivo del repositorio de la API. Así que básicamente queremos importarlo con esto y luego usarlo en esta línea aquí. Así que copiaremos esa declaración de importación. Así que los games.repository.ts, eso no es lo que quería. Esto, así que esto está bajo la API. Vale, y luego vamos a dar a estos objetos de juegos el tipo de array de juegos. Vale, así que ahora estoy importando de la biblioteca que acabo de crear y luego usando el tipo que se define allí. Bien, así que ese es el jugador. Luego vamos a construirlo y asegurarnos de que no hay errores. Así que, NxBuild API. Vale, bien. Así que, notarás aquí, cuando ejecuté NxBuild API, al principio estaba construyendo la biblioteca de interfaz de utilidad porque la interfaz de utilidad también tiene una tarea de construcción definida.

13. Construyendo y Moviendo Bibliotecas

Short description:

El proceso de construcción para la API lleva más tiempo en comparación con la construcción de otras partes. Mover la biblioteca de interfaz util a un nivel superior permite que sea utilizada por las aplicaciones API y CLI. Ahora, las aplicaciones API y CLI dependen de la biblioteca de interfaz util. El laboratorio 8 introduce el concepto de límites de módulos, que define reglas para las dependencias entre bibliotecas y aplicaciones.

Así que primero realiza la construcción para esto y luego realiza la construcción para la API en sí. NxBuild API es eso. Y luego, si lo ejecuto de nuevo, lo leerá de la caché y leeré esto de la caché. Así que no tomó tiempo en absoluto, mientras que este otro tomó, supongo, dos segundos. Así que no marca una gran diferencia para este pequeño ejemplo, pero para una aplicación más grande, marcará una gran diferencia. La versión de caché seguirá regresando en qué, 49 milisegundos. Mientras que, ya sabes, el paso de construcción real podría tomar, ya sabes, dos minutos hasta 30 minutos, dependiendo de lo que estés haciendo.

Bien, así que construimos eso y luego hagamos... Vamos a revisar el gráfico del proyecto aquí. Bien, aquí vamos. Actualicemos esto. Bien, ahora tenemos esta nueva biblioteca creada y las API dependiendo de ella. Eso es bueno. ¿Qué viene ahora? Vamos a confirmar todo, está bien. Así que confirmaremos bajo el laboratorio, laboratorio siete. Hm-mm. Bien, así que CLI hace llamadas a la API, pero está usando el tipo any, así que usemos el tipo en nuestro CLI así como en la API, pero el problema es que podríamos simplemente usarlo, pero la carpeta en la que está no tiene mucho sentido. La idea aquí es que todo en esta carpeta API solo se utiliza por la aplicación API, así que queremos mover esta biblioteca de interfaz util a un nivel superior para que esté directamente debajo de libs en lugar de debajo de la carpeta API. Así que si simplemente moviera esta carpeta, habría problemas con eso porque muchas de las opciones de configuración no se actualizarían correctamente, así que queremos usar el generador de movimiento para mover nuestra biblioteca, así que hagámoslo. Entonces, puedes, así que puedo hacer NXGMOVE o simplemente MV, y simplemente lo ejecutaré así. Así que dice, así que está ejecutando eso, así que necesita un nombre de proyecto, hagamos esto en realidad con NX console para poder entender qué estoy haciendo aquí. Así que MV aquí, MOV, ahí lo tienes. Y NX console tiene una función de simulación automática, así que quiero mover esta interfaz util, y quiero moverla en lugar de API slash interfaz util. Veamos, bien, aquí vamos. El problema era que este menú desplegable aquí tenía una lista obsoleta de proyectos, así que tuve que ir a NX console y hacer clic en actualizar aquí, y luego volver a abrir la pestaña de generación. Por lo general, no tienes que hacer mucho de esto de refrescar porque no estás creando nuevos proyectos cada 30 segundos, pero en este workshop lo estamos haciendo, así que. Así que, API interfaz util, y luego queremos moverlo a interfaz util, y luego está ejecutando esta simulación aquí, y así puedes ver los archivos que está creando. Así que está eliminando eso y moviéndolo, así que API slash y eliminando eso, y moviéndolo a un nivel superior. Así que eso parece lo que queremos. Si quisiéramos, también podríamos cambiar el nombre aquí, así como en el MV de Linux, así es como cambias los nombres, así que eso lo haría interfaz util cambiar nombre aquí, o podrías moverlo a una carpeta diferente aquí. Así que puedes hacer lo que quieras. Así que, si te estresas por cómo estás nombrando la biblioteca o dónde estás poniendo las ediciones, no te preocupes, siempre puedes moverlo más tarde. Así es como lo queremos, lo vamos a tomar de la carpeta API y moverlo a un nivel superior. Así que lo ejecutaremos, y ahora podemos ver los cambios que se hicieron. Um. Bien, lo moví de la carpeta API, ahora está aquí en el nivel superior, lo cual es bueno. Y ahora vamos a comenzar a usarlo en el CLI. Así que vamos a tomar esto y luego supongo, problemas de formato aquí, pero está bien. Aquí. Y en el main.ts del CLI, veamos, así que este val no es un NA, lo llamaremos game. Y necesitamos importar game aquí. Bien. Ahora, si volvemos a nuestras instrucciones, veamos el games repository.ts. Si te fijas en la, esta ruta de importación se actualizó automáticamente para nosotros. Solían ser API slash, y eso se actualizó cuando movimos nuestra interfaz util. Además, la ruta aquí se actualizó. Así que eso se encargó por nosotros, por el generador de movimiento. Bien, ahora si ejecuto, bien, voy a arreglar este alineamiento, porque esto es... Cambiar, no. ¿Está aquí? Clic derecho. Tres puntos, no. No, eso no es. Veamos si puedo encontrar... No quiero eso. Hmm. Aquí vamos, panel de línea. Posición del panel, inferior. Bien. Bien, ¿qué estaba haciendo? Ejecutar el gráfico siguiente. Este. Así que ahora actualizo esto. Bien, ahora tenemos el CLI y la API. Bien. Tengo que hacer un reinicio de NX aquí de nuevo. Por lo general, esto no lo hace. Así que esto, creo que hay un problema con la última versión de NX. Pero ahora la API depende de la API, así que ahora la API depende de la interfaz util y el CLI también depende de ella. Así que si esto cambia alguna vez, entonces ambos deben actualizarse para reflejar la nueva interfaz, lo que puede resolver una gran cantidad de problemas que puedes encontrar en producción o lo que sea. Bien. Lo tenemos. ¿Algo más en este laboratorio? No, eso es todo. Eso es el laboratorio siete. Voy a confirmar este laboratorio siete. Y bien, ahora vamos a ver el laboratorio ocho. Así que el laboratorio ocho, tenemos algunas diapositivas para eso. Bien, digamos que tienes una configuración como esta, donde tienes múltiples frameworks que se utilizan en tu repositorio. Así que tienes Angular, tienes Remix, tienes, no estoy seguro de qué, tal vez esto es Nest. No estoy seguro de qué... qué sintaxis es, pero alguna API backend, y tienes bibliotecas que todas se utilizan. Lo que queremos es tener algún tipo de reglas que digan que el Remix code solo puede usar el Remix code y el código JS simple en la parte inferior aquí. El código Angular usa el código Angular y esto, pero queremos tener alguna estructura en esto y tener reglas sobre qué bibliotecas pueden depender de otras bibliotecas. Así es como los límites de módulos se encargan de eso para nosotros. Así que si la API comienza a depender de algo en Remix, queremos poder decir, eh, no hagas eso. O si el JS simple comienza a depender de cosas específicas de la API, eso no está permitido. Esas son aplicaciones, esas son bibliotecas. Entonces, estas son como nuestras aplicaciones nombradas. Esta es una aplicación de administración, esta es una aplicación de tienda, esta es una aplicación de API. Y luego tenemos cosas compartidas en la parte inferior. Entonces, las aplicaciones solo pueden cargar bibliotecas, las bibliotecas solo pueden cargar bibliotecas. Así que queremos establecer estas reglas.

14. Estableciendo Límites de Módulos y Etiquetas

Short description:

Puedes definir sistemas de etiquetado para tu repositorio para agrupar cosas por tipo, nombre u otras dimensiones. La regla de lint 'enforce module boundaries' en NX te permite establecer restricciones en las dependencias. Puedes definir reglas para etiquetas específicas, como permitir que una biblioteca con la etiqueta 'util' solo dependa de otras bibliotecas con la misma etiqueta. También puedes establecer reglas para importaciones externas y prohibir dependencias transitivas. Al definir límites de módulos, puedes evitar dependencias circulares y controlar las dependencias entre las diferentes partes de tu repositorio.

Así que cualquier sistema de etiquetado que tengamos, vamos a poder definirlo para nuestro repositorio, agrupar cosas por tipo o por nombre, o por diferentes dimensiones. Y luego poder establecer reglas sobre cuáles son esas restricciones, sobre qué cosas pueden depender de otras cosas. Hay una regla de lint, llamada enforce module boundaries, que viene con nx. Así que puedes decir cosas como, si una biblioteca tiene esta etiqueta de tipo dos puntos util, que puede ser cualquier cadena que quieras aquí, puedes decir que el tipo util solo puede depender de libs que también tengan esa etiqueta de tipo util. Y no pueden depender de nada con react, como cualquier dependencia, como una dependencia de NPM, cualquier cosa con react o cualquier cosa con el espacio de nombres Angular. Así que eso es para lo que sirve esta regla de lint, enforce module boundaries. Hay tres subcategorías diferentes dentro de esta regla de lint, puedes decir solo depende de libs con una etiqueta específica, puedes hacer lo contrario, no puede depender de libs con una cierta etiqueta. Y puedes tener reglas sobre importaciones externas, que son como dependencias de NPM, cosas fuera del repositorio en las que no se les permite depender. Puedes tener una regla sobre prohibir dependencias transitivas, decir si estás usando, si dependes de, no sé, express, que está usando otras dependencias como no sé, choked o algo así. Y luego estás usando choked o dentro de tu propia, dentro de tu aplicación. Podría funcionar, podría compilar y funcionar correctamente. Pero luego si express deja de usar esa dependencia, entonces te encontrarás con una aplicación rota sin darte cuenta de lo que sucedió. Veamos. Así que puedes decir que no hagas eso. Puedes verificar las importaciones externas anidadas. No estoy seguro exactamente de qué se trata eso. Así que si quieres, por defecto, no te permite hacer una dependencia circular. Así que si dependes de una biblioteca que depende de la primera biblioteca, te impedirá hacer eso. Pero si ya tienes eso y estás tratando de adoptar Nx, puedes decir, OK, solo permite eso por ahora hasta que resuelva ese problema. Así que esas son las diapositivas para límites de módulos. Déjame mirar aquí. Sí, entonces, Jannick, si ves cosas que no deberían estar allí, puedes ejecutar NxReset para restablecer eso. Pero parece que lo resolviste. De todos modos, Jannick dice que Nx parecía saber que era una biblioteca porque la mantuvo en la carpeta libs. Sí, por lo general, si las cosas ya son bibliotecas, entonces las mantendrá en la carpeta de bibliotecas. Aquí hay una propiedad en Project JSON, tipo de proyecto, esto puede ser aplicación o biblioteca. Y eso solo determina en qué carpeta se coloca cuando estás usando la configuración integrada. Pero puedes cambiar esto libremente si quieres. Así que aquí, esta es la biblioteca del proyecto. Ahí es donde Nx lo sabía. Así que hagamos el siguiente laboratorio donde establecemos algunos de estos límites de módulos. Entonces, para configurar etiquetas, vamos a ir al archivo project.json de cada proyecto. Y vamos a configurar algunas etiquetas de alcance y algunas etiquetas de tipo. Así que para el alcance, vamos a configurar un alcance de CLI, un alcance de API, y un alcance de shared. Y luego, para el tipo, el tipo podría ser aplicación, tipo app. Y luego, para las bibliotecas, podemos hacer tipo util. Veamos. Entonces esto va a ser un tipo util. Y luego auth, ¿cómo deberíamos llamarlo? Podemos darle un tipo de probablemente acceso a datos. Así que en esta etiqueta aquí, podemos hacer esto, ya sabes, cualquier cadena que queramos aquí. Así que le daré un alcance de API, le daré un tipo de acceso a datos porque está accediendo a los datos de autenticación. Y luego este, esta es la biblioteca de interfaz util. Así que este es un alcance de shared y le daremos un tipo de util. Y luego tenemos otros dos proyectos para actualizar. Así que este es un alcance de CLI y un tipo de app. Esta es la aplicación de API, así que le daremos un alcance de API. Tipo app. Podríamos hacer lo mismo para las aplicaciones end-to-end, que en realidad no hemos usado en absoluto. No tiene etiquetas. OK. Si hay un proyecto aquí que en realidad no importa, así que esta aplicación end-to-end en realidad no importa Así que esta aplicación end-to-end en realidad no importa nada de código de la aplicación API, pero queremos ejecutar las pruebas end-to-end siempre que esta aplicación API cambie. Así que puedes agregar manualmente una línea en el NXGraph definiendo estas dependencias implícitas aquí. Esto es simplemente decir manualmente, quiero una línea donde API ETE depende de API. Así que hay casos en los que necesitas hacer eso. Así que voy a agregar una propiedad de etiquetas aquí. Y te das cuenta de que aquí tuvimos autocompletado. Porque esto viene de un NX console, leyendo el esquema para el proyecto JSON y sabiendo qué propiedades van aquí. Así que etiquetas, esto es, supongo, alcance API. Porque es una API y prueba. Y luego tipo, bueno, nos da un tipo de ETE porque es diferente de una aplicación. Pero puedes nombrar esto como quieras, lo que tenga sentido para ti. Básicamente, basado en lo que quieras que sean tus reglas. Así es como debes configurar tus etiquetas. Alcance CLI y tipo. Permíteme ejecutar el gráfico NX nuevamente. Y en el gráfico, en realidad muestra cuáles son las etiquetas. Así que si haces clic en estas cosas, muestra alcance API, tipo ETE. Y esto es alcance share, tipo UTIL. Así que esto puede ser útil. Así que ahora creo que nos va a hacer el. Así que configuramos todas las etiquetas aquí. A continuación, vamos a definir nuestras restricciones de dependencia. Así que en el archivo root esland rc.json, vamos a agregar esto. Vamos a modificar esta regla y establecer algunas restricciones de dependencia. Así que voy a copiar esto. Y luego vamos a eslandrc.json. OK, esta es nuestra regla aquí, NX Enforced Module Boundaries. Y dependency constraints. Así que esta configuración predeterminada aquí está diciendo que cualquier proyecto puede depender de cualquier otro proyecto. Así que queremos ser más restrictivos que eso. Así que queremos eliminar eso y agregar nuestras propias reglas aquí. Así que si es el alcance de CLI, déjame minimizar esto. Así que el alcance de CLI puede depender de CLI y shared. ¿OK? Entonces agreguemos algunos más. Si es un alcance de API, entonces puede depender de otras cosas de API y shared. Si es un alcance de shared, puede depender de otras cosas que sean compartidas. Eso es todo. Ahora vamos a establecer algunas reglas para los tipos. Así que si es un tipo de app, en realidad debería poder depender de. Puede depender de cualquier cosa.

15. Análisis de código y prohibición de importaciones en CLI

Short description:

Probamos el análisis de código y nos aseguramos de que esté funcionando. También demostramos cómo prohibir la importación de Express en el CLI. Los nombres de los objetivos son arbitrarios, excepto para el objetivo de construcción. Al dividir una aplicación existente en bibliotecas, ejecutarías 'index init' para configurar un archivo base index.JSON. Luego, generarías una biblioteca para la carpeta deseada y copiarías manualmente el código. Finalmente, actualizarías las referencias en la aplicación. Este proceso requiere algo de trabajo manual debido a la complejidad involucrada.

Así que podemos dejar eso sin especificar. Sí. Así que podemos hacer un tipo data access. Puede depender del tipo data access o del tipo util. Y luego el tipo util solo puede depender del tipo util. Bien, hagamos una comprobación de cordura aquí y hagamos Así que podría hacer un Nx Lint API para ejecutar el lente en un proyecto en particular, o podría hacer Nx run many con un objetivo de API, y esto por defecto ejecutará, no el objetivo API, sino el objetivo Lint. Y esto ejecutará el objetivo Lint en todo el repositorio. También podrías especificar una lista de objetivos con una lista de proyectos con una bandera de proyecto de guión doble, pero queremos ejecutarlo en todo. Así que hagamos esto. Bueno, parece que todo sigue funcionando, así que veamos si podemos romper esta regla de Lint y asegurarnos de que realmente está funcionando. Así que hagamos que una biblioteca util use una biblioteca data access. Así que iremos a la interfaz util aquí, y aquí vamos a añadir una importación, queremos importar la función doauth. Bueno, así que la importó, la encontró, lo cual es agradable. Así que ahora ejecutemos la regla de Lint en, en realidad, sí, no lo haría, en el nxLint util interface, tenemos un error. Así que dice bibliotecas construibles, no pueden importar o exportar de bibliotecas no construibles, bueno, ese es un error diferente al que esperaba. Así que ese es un problema donde este tiene un objetivo de construcción, mientras que API-Auth no tiene un objetivo de construcción. Solo añadiremos algo aquí, pasará por alto eso. Así que añadimos un objetivo de construcción que no hace nada aquí, así que este es el error que estaba esperando. El proyecto etiquetado con el alcance compartido puede solo depender de vidas etiquetadas con el alcance seguro. Bueno, ese no es exactamente el error que estaba esperando, pero también es válido porque este tiene Util Interface tiene alcance compartido y API-Auth tiene alcance API. Así que eso no debería estar permitido por esa razón. Esta regla también fue violada, pero encontré esta primero. Así que podríamos hacer lo mismo. Sí, podríamos tener un CLI importando la función do-auth y eso también violaría esta regla aquí. Estas reglas son arbitrarias, puedes configurarlas como quieras. Pero esta es una característica poderosa que puede imponer alguna estructura a tu base de código. Sí, está bien. ¿Podrías prohibir express desde el CLI? Déjame responder a esa pregunta primero. Si lo hicieras, veamos. ¿Cómo lo hiciste? Sí. Así que haces esto. Así que la etiqueta de origen es el alcance CLI. Podemos añadir otra propiedad aquí. Supongo que no se autocompleta. Queremos añadir una banda de importaciones externas. Creo, ¿es eso? Déjame buscar la documentation aquí. Nx.dev es el sitio de documentation. Quiero ir a los paquetes, y quiero encontrar el linter. Linter aquí. Y luego, solo haré una búsqueda de módulo de fuerza. Seguro. Haré una búsqueda de bandas de importaciones externas. Así que esto está bajo los paquetes. Oh, aquí está. Así que es el paquete eslintplugin.nx. Así que aquí están las opciones aquí. Así que podemos añadir solo depende de las vidas con etiquetas. Eso es lo que hemos estado usando en su mayoría. Pero también podemos hacer bandas de importaciones externas. Así que esto es una matriz de paquetes. Así que aquí, bandas de importaciones externas. Así que eso es correcto. Y luego, es una matriz. Y luego, podría poner express aquí. También puedes usar un comodín allí. Express estrella. Así que ahora, si voy a CLI aquí, y quiero importar de Express. No le gusta. Así que dice, hey, no hagas eso. No está permitido. Sí. Así que Janik dice que los nombres de los objetivos son arbitrarios. Son arbitrarios excepto para el objetivo de construcción. Hay alguna lógica extra alrededor de la construcción. Creo que eso es todo. Tenemos un término llamado biblioteca construible, que simplemente significa que tiene un objetivo de construcción. También hablamos de bibliotecas publicables, pero no creo que tengamos ninguna lógica especial alrededor de eso. Simplemente se refiere a las bibliotecas que tienen un objetivo de publicación. Así que solo haré un atajo para eso. Había otra pregunta aquí arriba. Así que Janik estaba preguntando sobre cómo recomiendas dividir una aplicación existente. Así que para una aplicación existente, ejecutarías. Así que para empezar, ejecutarías index init para simplemente instalar index y configurar un archivo base index.JSON. Y luego una vez que tienes una carpeta aquí que quieres convertir en una biblioteca, lo que harías es que si quisiera que este repositorio de juegos fuera su propia biblioteca, básicamente haría index generate una biblioteca y la llamaría repositorio, tal vez repositorio de juegos. Y luego supongo que sería JS, lo que quieras que sea. Y luego básicamente tendrías que copiar este code en esa biblioteca recién creada. Así que copiarías eso y luego todas las referencias a eso tendrías que actualizarlas manualmente dentro de esta aplicación misma. Así que hay un poco de proceso manual involucrado allí. Porque hay demasiada complejidad para hacerlo automáticamente por ti. OK. Así que añadimos eso. Creamos esto. Hicimos run many. Probamos eso. Probamos eso. Probamos eso. OK. Asegurémonos de que nuestro análisis de código está funcionando. Nx run many. Lo otro que podríamos hacer, quiero mostrar esto en realidad.

16. Comando Nx Affected y Configuración de CI

Short description:

Quiero mostrar el comando Nx affected. Primero, necesito asegurarme de que el linting esté funcionando. Después de solucionar un problema con las reglas de lint, el linting ahora está funcionando correctamente. El comando Nx affected te permite ejecutar un cierto objetivo en proyectos que se vieron afectados por un cambio de código. Examina tu historial de git y se puede configurar con una rama base. Esto puede acelerar significativamente tu tiempo de CI al omitir pruebas innecesarias. Tenemos tiempo para un tema más, y la audiencia votó para centrarse en la configuración de CI y la caché distribuida. Creamos un archivo de flujo de trabajo de CI que ejecuta npm install y pruebas para el CLI y la API. Hacemos commit del archivo y lo empujamos a main. Eso es todo para el laboratorio 11, y ahora podemos pasar al siguiente tema.

Quiero mostrar el comando Nx affected. Bien. Permíteme asegurarme de que el linting esté funcionando primero. Nx run many. Target equals lint. Uno falló. Necesito arreglar esto. Así que el VS code no ha alcanzado nuestras nuevas reglas de lint. Así que si quieres arreglar eso, reinicias el servidor ES lent. Y ahora tiene las marcas correctas. Eso es porque cambiamos la regla. Y simplemente necesitaba ser actualizado. Vale. Así que si arreglo eso, ahora nuestro lint debería estar funcionando. ¿Notaste lo rápido que fue eso? Eso es porque la mayoría de estas cosas estaban en caché. Estos cinco objetivos de lint ya estaban en caché, y solo necesitaba ejecutar este que acabo de cambiar. Así que si lo ejecuto de nuevo, es instantáneo de nuevo. Vale. Así que eso. Ahora déjame hacer commit de esto, y luego quiero mostrar el comando nxaffected. ¿Cómo es este laboratorio 8? Digamos que si quisiera deshacer esto, podría, en lugar de hacer nxrunminny para comprobar y ver qué necesito ejecutar, puedo ejecutar nxaffected. Y así este comando ejecuta un cierto objetivo. Target equals lint. Así que esto está diciendo que ejecute el comando lint en cualquier proyecto que se viera afectado por un cambio de code en particular. Así que ahora, he afectado este archivo. Así que mira tu historial de git. Y puedes configurar una rama base contra la que estás comparando, si quieres. Puedes configurar la base y la cabeza. Pero la cabeza por defecto es eso. Y en realidad, creo que la cabeza por defecto es tu configuración de trabajo actual. Y luego la base es la cabeza, creo. Sí, la cabeza es no sé cómo decir en Git lo que sea que esté actualmente en tu sistema de archivos. Pero así que si ejecuto esto, se ejecutó. Veamos, nx run, nx affected. Así que se ejecutó. Así que esta interfaz util, así que lo ejecutó para un CLI. Lo ejecutó para API end to end y API end to end. Así que lo ejecutó para cinco proyectos, lo cual tiene sentido porque este repositorio de juegos no se ve afectado. Y veamos, ¿qué más no se ve afectado? API auth no se ve afectado. No hay razón para que el lint de API auth se vea afectado por este cambio de code. Pero estos otros, podrían potencialmente ser modificados por el lint podría fallar porque he modificado algo de code aquí. Así que eso puede acelerar significativamente tu tiempo promedio de CI porque no estás ejecutando pruebas que ni siquiera necesitan ejecutarse. Así que eso es el laboratorio ocho límites del módulo. Nos queda media hora. Veamos qué queda y seamos estratégicos sobre lo que queremos hacer. Así que creo que tenemos tiempo para hagamos un, voy a dejar de compartir mi pantalla. Y para las personas que han aguantado hasta ahora, tienen el poder de votar sobre lo que hablaremos a continuación. Así que podemos trabajar en hacer nuestros propios generadores que son locales a tu repositorio, o podríamos trabajar en la configuración de CI y la caché distribuida. Así que vamos a hacer uso de la función Zoom, levantar la mano. Veamos dónde está la función Levantar la mano. Pensé que sería una reacción, pero ahí está. Sí, bajo Reacciones. Así que puedes levantar la mano así. Así que levanta la mano si te gustaría hacer. Así que las opciones son generadores, generadores personalizados, o CI y caché distribuida. Así que levanta la mano si quieres hacer generadores. Generadores personalizados. Así que tengo dos votos para los generadores. OK, tres votos para los generadores. Puedes desactivar el silencio si estás tratando frenéticamente de encontrar el botón de Reacción. Bueno, hagamos votos para el CI y la caché distribuida. 1, 2, 3, 4, OK, parece que la caché distribuida lo gana. Bien, así que si quieres ver los generadores, puedes hacerlo por tu cuenta. Eso son los laboratorios 9 y 10. Pero voy a saltar al laboratorio 11. Así que el laboratorio 11 aquí. Vamos a configurar CI. OK, así que esto es configurar la caché distribuida. Configurando CI. En realidad, espera, ¿lo hice? Sí, eso es correcto, OK. Laboratorio 11. Espera. OK, así que estamos en main. Necesitamos hacer commit. Así que vamos a copiar esto y vamos a crear un workflow.ci.yaml. ¿Qué eran todas estas? Eso debería estar bajo.github. Ahí. Nueva carpeta. Aquí..github, y creo que es workflows. Y luego un nuevo archivo. Ci.yaml. Pega eso. OK. Así que lo que esto está haciendo es, cada vez que hay un PR, estamos ejecutando npm install. Estamos comprobando lo último. Estamos ejecutando las pruebas para el CLI y ejecutando las pruebas para la API. ¿OK? Así que hacemos eso. Y luego hacemos commit de eso a main y lo subimos. Bien. Así que déjame llegar a, ¿es esto 11? No recuerdo.

17. Realizando Cambios y Actualizando CI

Short description:

Empujamos los cambios al repositorio y creamos una solicitud de extracción. Las pruebas unitarias están fallando, pero resulta que no hay pruebas. Actualizamos la configuración de CI para usar nx affected en lugar de objetivos específicos. Hacemos commit de los cambios y ejecutamos las pruebas. Las pruebas pasan, pero está claro que nuestras pruebas unitarias no son suficientes. Discutimos la ejecución de pruebas en paralelo y agregamos más pasos a la configuración de CI. Sin embargo, hay un problema con la rama principal que no se está comprobando en CI. Hacemos los ajustes necesarios y continuamos con el proceso.

Empújalo a. OK. Así que lo empujamos a mi. OK. Eso está funcionando. Eso está empujado. Añadir un CI. OK. Así que vamos a abrir una nueva rama. Comprobamos nuestro dash b. Modificado. Y luego nueva rama y actualizamos nuestro main.ts. Hacer algún cambio. Vamos a hacer, en realidad, el cli, main.ts, porque esto realmente afectaría algo. OK. Así que ese es el nuevo mensaje que se mostrará en el cli, el terminal, y los cambios del committer y lo empuja. OK, cambios realizados. Estos son mensajes de commit realmente geniales. Es como las Manos. Si has visto ese cómic de xkcd. Así que lo empujamos. OK. Y luego vamos a nuestro repositorio aquí, bg work. Primero, usa la barra. OK. Así que vamos a hacer un PR aquí. Gran solicitud de empleado. Así que hemos hecho eso. Y luego veremos esto. Las pruebas unitarias están fallando. Veamos. Así que está ejecutando esto. Así que está ejecutando la prueba CLI, ejecutando la prueba API. Y volveremos a comprobar eso en un rato. Así que estamos configurando eso. OK. Así que queremos actualizar esto para usar solo index affected en lugar de específicamente. En lugar de hacer dos trabajos diferentes aquí. Así que sí, gracias. El enlace xkcd. Así que voy a actualizar el CI.yaml. Así que en lugar de test-cli, estamos haciendo test-affected. Y en lugar de ejecutar npx nx-test-cli, vamos a hacer nx affected dash dash target equals test. Todos afectados. Y luego ya no necesitamos esto. Así que ese es el cambio que necesitaremos hacer. Déjame ver si debería hacerlo en main o en nuestra rama. Vamos. Ok, así que vamos a comprobar esto doblemente. ¿Qué es eso, pasó? Interesante. Parece que nuestras pruebas unitarias no son muy buenas. Um, así que corrió sí, el x, las pruebas de next cli, Oh, no se encontraron pruebas. Eso es lo que ha pasado. Buen trabajo. Buen trabajo. Hemos tenido éxito en no ejecutar ninguna prueba. Ese es el mejor tipo de pruebas. Así que, um, ya sabes, annex affected no es, no es útil. Si no tienes realmente, uh, no tenemos realmente ninguna prueba, entonces es, ya sabes, estás viviendo en el salvaje oeste en ese punto. Um, ok, así que sigamos adelante. OK. OK. Así que hicimos ese, ese trabajo. Um, pruebas, he estado corriendo secuencialmente para cada proyecto. Puedes correrlos en paralelo. Um, por defecto, um, dash dash parallel se establece en tres. Um, si quieres hacer eso más, puedes, ya sabes, cambiar el número. Um, o creo que haces parallel equals one. Hazlo en secuencia. Um, así que déjame, déjame hacer commit de esto y. OK. Así que estoy haciendo commit de eso y luego veremos, um, veamos qué hace aquí en un rato. Um, OK. Así que solo esas pruebas, así que también podemos, tenemos que hacer Lint ET y build. Um, así que podemos añadir más pasos aquí. Así que idealmente querríamos hacer, um, eso y luego hacer, uh, Lint y build. Um, no estoy seguro si esto está en el último NX, pero pronto podrás hacer esto. Ellos, um, en lugar de tener cuatro mentes diferentes. Um, pero, pero ahora creo que tienes que hacer esto, todos los objetivos. Déjame comprobar solo este aquí. OK. OK. Así que este se ha actualizado y así que no el objetivo de la prueba está fallando o está fallando números son get main en revisión o ruta no en el árbol de trabajo. Oh, OK. Así que ese problema es porque no tenemos la, la rama principal comprobada y CI, así que necesitamos, déjame ver aquí. Asegúrate de que esto está configurado correctamente. Eso es correcto. Eso es correcto. Vamos a comprobarlo.

18. Configuración de CI y Caché Distribuido

Short description:

Este laboratorio se centra en la configuración de CI para usar NX affected y ejecutar solo las pruebas de código necesarias. Otro tema cubierto es el caché distribuido utilizando NX cloud. El laboratorio demuestra cómo especificar operaciones que se pueden almacenar en caché y proporciona un token de acceso para conectarse a NX cloud. Los resultados de la ejecución, incluyendo los aciertos y fallos de caché, pueden ser visualizados en NX cloud.

La rama que la PR está utilizando y CA probablemente no tengo la última rama al revés. No quieres revisar cada rama. Creo que eso es lo que hace esto. Así que en tu CI, probablemente querrás hacer algo diferente. Pero volvamos aquí. Y está bien, ¿dónde está el? ¿Dónde estamos obteniendo las acciones? Obtén acciones de hub. Vamos. Por alguna razón, no aparecía en eso archivo de flujo de trabajo inválido, 913. OK, así que no le gusta esto. Así que necesito otra sangría. Quizás. Veamos eso. OK, así que le gusta el archivo YAML. Eso es bueno. Todavía se llama prueba CLI, y eso es porque yo nunca no cambié ese nombre. Pero solo hay uno de ellos, que es lo que esperamos. Y falló porque, OK, así que todavía no está revisando la rama principal aquí. La base necesita estar disponible para él. OK, bueno, tenemos que actualizar eso. Antes de ejecutar NXEffected, necesitas hacer esto. OK. Así que encontré esto en los docs aquí, buscando GitHub actions. Encontré esto al configurar eso, configurar eso, y luego está este nodo aquí. Si estás usando la acción en el contexto de una rama, necesitas agregar esto, obtener seguimiento de la rama principal, origen principal, antes de ejecutar NXEffected. Ya que el origen principal no existe. Déjame asegurarme de que también estamos usando eso. Así que esta acción aquí te ayudará a poder verificar cuál puedes ejecutar afectado en base al último despliegue exitoso si estás haciendo CI. En nuestro caso, probablemente no lo necesitamos porque esto es solo para ejecutar pruebas y construir letten. Pero para una acción de despliegue, querríamos hacerlo en base al último despliegue exitoso, no solo al último medio en el principal. Vamos a subir esto. Correcto, así que entre nuestra privación y usuario y usuario solo, empujaremos los dos primeros. Esta es la hora. Vamos a saltar un poco. Y este es bueno, porque hay un Joker diferente que puedes enviar en lugar del último delegado y desplegar. Pero digamos que tenemos un Joker y queremos ponerlo en nuestra construcción, y luego devolveremos nuestra respuesta. Así que vamos a enviarla. Vale, deja que eso falle. OK, algo raro pasa aquí. Voy a renunciar y pasar al siguiente laboratorio. Así que básicamente, todo este laboratorio trata sobre configurar tu CI para usar NX affected. Y luego ejecutar, ejecutar solo, solo testing el code que necesitas probar. Así que, ese es un aspecto de configurar CI. Lo otro que quería mostrarte para asegurarme de que no nos quedamos sin tiempo está en el próximo laboratorio. Laboratorio 12, caché distribuido. Así que, puedes ejecutar esto o puedes ejecutar NX connect to NX cloud. Y, así que básicamente está diciendo sí a la cosa a la que dijiste no antes. Y lo que eso hará es que añade un, otro paquete aquí, este paquete NX cloud. Y añade algunas configuraciones a tu archivo NX.json. Cambia el corredor del local sistema de almacenamiento en caché de tareas a usar el sistema de almacenamiento en caché distribuido NX cloud. Así que, y luego también, creo que estas son solo las operaciones de caché por defecto. Así que puedes especificar qué cosas tienen sentido almacenar en caché aquí. Así que construir normalmente es cacheable. Básicamente es cualquier cosa que es, solo cambiará en base a, la salida solo cambia en base a las entradas. Cosas como servir no tienen sentido ser almacenadas en caché aquí porque no hay salida para almacenar en caché. Cosas como cualquier cosa que esté haciendo una llamada a la red. Así que a veces las pruebas ETE no deben ser almacenadas en caché si están haciendo una llamada a la red a algún otro servidor que no estás, como controlando y la prueba de intención. Pero depende de ti cómo, dependiendo de cómo escribiste tu prueba de intención, eso podría ser almacenado en caché o no podría ser almacenado en caché. No sé, hay algunas otras cosas que no tienen sentido ser almacenadas en caché. Como un despliegue, no quieres almacenar en caché tu paso de despliegue. Así que defines qué debe ser almacenado en caché aquí y luego esto, añadiendo en X cloud también te dio este token de acceso. Y entonces lo que vamos a hacer es, así que cuando ejecutamos esto, nos envió este enlace aquí para reclamar nuestro espacio de trabajo en NX cloud. Y entonces yo solo crearé un cloud. Solo continuaré con Google y usaré mi cuenta normal. Sí. Así que este es el token de acceso. Así que este es el que está en el archivo NX.json. Es este token de acceso. Digo, hey, este es mi espacio de trabajo. Así que déjame conectarlo. OK. Así que ahora lo que esto hace es cuando ejecuto, puedo ejecutar NX build CLI aquí. Así que ejecutó con éxito dos objetivos. Este mensaje no estaba aquí antes. Así que si hago clic en este enlace aquí, lo traigo de vuelta, puedo ver los resultados de esta ejecución. Así que esto significa que fue un, veamos, fue un fallo de caché aquí. Esta marca significa que fue una ejecución exitosa. Todos tomaron menos de un segundo, a pesar de que fue un fallo de caché. Pero esa es la información al respecto. Ahora también podría, podría ejecutar esto de nuevo, y esta vez leer la salida de la caché para tres de tres tareas. Así que miraré aquí de nuevo. Sigue abriéndolo en una ventana separada aquí. Todavía un éxito, pero ahora este icono aquí cambia. Fue un acierto de caché local. Eso es lo que significa este icono aquí. Así que lo leyó de mi máquina y lo cargó. Ahora, puedo, voy a hacer esto. Caché estricta Diga commit largo, seguro. Empuja eso, empuja eso. En realidad, déjame revisar el principal. Um, Bueno aquí, voy a fusionar esto y luego revisarlo.

19. Uso de caché remota y NX Cloud

Short description:

Fusionar y confirmar la fusión. Verifique el código en una carpeta diferente y demuestre el mecanismo de caché. Ejecute NPM install y Nx build CLI. Descargue mi repositorio y ejecute Nx build CLI. Configure un nuevo token. Confirme y empuje los cambios del bloqueo del paquete. Ejecute Nx build CLI nuevamente. Limpie la caché usando NX reset. Ejecute Nx build CLI para buscar la caché remota. El informe muestra que dos tareas se realizaron de forma remota. NX Cloud es un producto de pago para repositorios más pequeños.

Fusiona eso, confirma la fusión. Ahora voy a, lo que voy a hacer es que voy a revisar esto en una carpeta diferente, um, en una carpeta diferente. Copia eso. Y voy a mostrarte el, el mecanismo de caché. Clona esto y luego BG hoard copy. Voy a code, BG hoard copy. Vale. Voy a ejecutar NPM install para configurar todo. ¿Cuál fue el comando que ejecuté, ejecuté? Creo que fue construir el CLI. Sí. Nx build CLI. Vale. Así que ejecuté eso y ahora voy a ejecutar Nx build CLI aquí. Y este es un repositorio completamente diferente. Podría ejecutar esto en una máquina diferente, pero sería más difícil para mí configurarlo. Pero si quieres probar esto tú mismo, puedes descargar, descargar mi repositorio y ejecutar Nx build CLI. Ahora eso es un repositorio completo. Descarga mi repositorio y ejecuta Nx build CLI. Y así se ejecutó con éxito el objetivo de construcción y una tarea depende de el cero ejecutado desde la caché. Veamos. Me pregunto si eso es porque tengo un token de solo lectura configurado. Vale. Así que fue una falla de caché y lo ejecutó todo de nuevo. Así que déjame ver. Vale. Así que voy a configurar un nuevo token aquí. Así que hay dos tipos diferentes de tokens, configuraciones de EG horde, administrar tokens. Hay dos tipos diferentes de tokens. Ahora este es un token de lectura y escritura. ¿Por qué es diferente? Hmm. Me pregunto si, oh, hay un cambio aquí. ¿Qué es diferente? Mi bloqueo de paquete cambió. Vale. Así que eso rompió el, um, el siguiente build CLI aquí. Huh. Vale. Voy a confirmar esto. Cambios en el bloqueo del paquete. Empuja esto. Así que porque el bloqueo del paquete cambió, um, debería, correctamente rompió la caché correctamente dijo, necesito ejecutar esto de nuevo porque, um, si hay diferentes, uh, un bloqueo de paquete diferente, entonces eso significa que tenemos un diferente. Diferentes entradas en el sistema. Um, así que voy a ejecutar esto en el índice veremos mentira de nuevo. Vale. Así que eso correctamente lo ejecutó, lo leyó de la caché. Déjame volver al ahora. Ahora estamos, estoy en el repositorio original aquí. Um, y voy a. Um, obtener la comprobación principal. Oh, creo que ese es, ese es el problema. Um, estaba en una rama diferente y había algunas otras cosas que eran diferentes, um, y si instalas, vale, así que nada, nada es diferente aquí. Vale. Um, por defecto, um, la caché se almacena dentro de los nodos modules. Um, punto de caché es la carpeta NX aquí. Um, y esto tiene un hash para cada, cada comando que he ejecutado y luego las salidas de ellos. Así que la salida terminal y la. Sabes, las salidas de la carpeta dist para cada una de estas cosas. Aquí es donde se leen las cosas. Um, así que voy a ejecutar NX reset que limpiará esa caché aquí. Muéstralo, no lo hice. Um, NX, uh, hay un comando para limpiar la caché. Déjame encontrarlo. Um. O puedo simplemente eliminar la carpeta, pero, um. No lo haría. Tal vez. Tal vez es solo. Vale. Eso fue solo mi sistema de archivos. El VS code pensó que todavía estaba allí, pero no lo estaba. Vale. Así que NX reset sí, sí se deshizo de él. Um, así que eliminó esa carpeta. Así que ahora si ejecuto NX build CLI, debería ir a buscar el remoto que se creó, creado aquí. Sí. Y, y cargado. Así que el siguiente proyecto CLI, um, ahí vamos. Así que este fue cargado desde la caché remota. Um, así que leyó la salida de la caché en lugar de ejecutar el comando para dos de dos tareas. Um, reutilizó dos pruebas. Así que dos de ellas fueron, fueron hechas de forma remota. Así que si miro este, este comando, este, uh, informe aquí. Oh sí. Este informe. Así que este, este icono aquí dice que es una caché remota. No es, en lugar de localmente en mi computadora, fue remoto tirando hacia abajo desde, desde un experto y X cloud. Así que, um, y luego puedes, sabes, obtener la salida terminal si quieres. No salida terminal para ese, este tenía plazo. Así que NX cloud es un, es un producto de pago. Um, pero es, um, para repositorios más pequeños.

20. NX Cloud: Caché Distribuido y Ejecución de Tareas

Short description:

NX Cloud ofrece caché distribuido y ejecución de tareas distribuidas. El caché distribuido ayuda con el caso de uso promedio, mientras que la ejecución de tareas distribuidas paraleliza las tareas de la manera más eficiente posible. NX Cloud es la única parte de pago, y NX en sí es completamente gratuito. La comunidad ofrece recursos como el Slack de la Comunidad, cuentas de Twitter, videos de YouTube e interacciones en GitHub. Gracias por su atención y por ver hasta el final del video.

Es, um, hay, hay una, una gran capa gratuita. Entonces, si tienes como 10 desarrolladores, um, probablemente nunca, nunca superarás la capa gratuita. Creo que tenemos, uh, 500 horas de, de tiempo de cálculo, um, de, de tiempo ahorrado por mes, uh, gratis. Um, entonces normalmente. Ya sabes, una pequeña organización, nunca llegarás a eso. Y es gratis para cualquier tamaño, si es, si es un repositorio de código abierto. Um, entonces, para organizaciones más grandes, hay una, hay una versión de pago. Um, y también hay una versión enterprise. Si quieres. Si quieres alojar el caché en tus propios servidores, um, eso puedes habilitarlo de esa manera. Um, entonces, esto se configura para que, ya sabes, en toda tu organización, si, si alguien alguna vez, um, ejecuta una compilación en un conjunto particular de code, um, puedes compartir ese trabajo para cualquier persona en toda la organización.

Muy bien. He estado hablando durante mucho tiempo y no he mirado, um, mirado las preguntas. Así que déjame ver si me he perdido algo. Um, Muy bien. No veo preguntas. Entonces, um, nos quedan unos minutos. Um, ¿qué, uh, qué otras preguntas tenemos? ¿Hay alguna manera de hacer caché distribuido sin NX cloud? Um, teóricamente podrías hacerlo por tu cuenta, um, hay, quiero decir, NX en sí, en sí es de código abierto. Um, NX cloud no es de código abierto, pero si quisieras escribir el tuyo. Um, mecanismo de caché distribuido. Um, podrías hacerlo, esa parte no es demasiado difícil. Um, la otra pieza que olvidé mostrarte es la, um, entonces el caché distribuido es genial para tu, um, para tu caso de uso promedio. Déjame compartir mi pantalla de nuevo. Um, Entonces podrías teóricamente, um, no sé, en, en una semana o dos de tiempo de desarrollo, escribe el tuyo. Caché distribuido, simplemente encuentra, encuentra la API y el índice de origen code y, y escríbelo tú mismo. Um, pero no sé por qué necesitarías, uh, francamente, um, porque el precio no es, no es malo. Um, pero la otra característica que quería mostrarte que NX Cloud también ofrece es, um, ejecución de tareas distribuidas aquí. Um, entonces el caché distribuido ayuda con el caso promedio. Um, y entonces, ya sabes, si, si has, um, si, ya sabes, modificas algo que alguien ya ha, ya ha hecho, entonces simplemente usas su, sus, um, sus resultados. Um, pero ¿qué pasa si modificas algo que está en la raíz de tu, de tu repositorio o algo que nadie ha, ha calculado ya para ti. Um, entonces necesitarás algo como la ejecución de tareas distribuidas. Y lo que hace es que, um, automáticamente ayuda a paralelizar todas tus tareas de la manera más óptima posible, um, porque NX conoce tu gráfico de dependencias. Um, Entonces normalmente tu, cualquier intento de paralelizar cosas en el CI se parece a esto, donde tienes, si tienes, tienes tres corredores diferentes, tienes algo de tiempo de inactividad y luego ejecutas pruebas y algo de tiempo de inactividad en tus compilaciones y luego algo de tiempo de inactividad después, y luego aterrizas y luego un montón de tiempo de inactividad después, entonces, ya sabes, configurar manualmente qué, qué tareas se ejecutan en qué servidores. Um, pero lo que hace DTE es que. Solo le dices cuántos agentes quieres y, um, y luego automáticamente. Divide las tareas entre esos agentes de la manera más eficiente posible porque sabe, uh, qué tareas necesitan ser ejecutadas antes de qué otras pruebas. Entonces dice, voy a ejecutar esas primeras en este agente. Y tan pronto como eso esté hecho, voy a agregar otras pruebas encima de eso. Así que hace el mejor uso posible de cuántos agentes tienes. Y si alguna vez necesitas escalar, simplemente cambias un tres por un diez y es instantáneamente escalado a 10 agentes. Um, mientras que si lo hicieras manualmente, eso sería mucho trabajo para intentar configurarlo. Um, y eso, eso es la, eso es la característica que te llevaría, yo no sé, no sé, tres o cuatro meses de tiempo de desarrollo para. Para llegar a donde está ahora. Y para entonces, habríamos, habríamos pasado a otra cosa. Um, para agregar más características y cosas. Entonces, um, y eso es, eso es una característica más asesina que el caché distribuido es incluso. Porque eso, eso te ayuda con tu, con tu peor escenario. Algo que, ya sabes, tomaría dos horas, tomará media hora. Mientras que el caché distribuido básicamente tomará tu promedio de promedio de media hora y hará que tu maquillaje sea un promedio de 15 minutos o algo así. Muy bien. ¿Otras preguntas? Puedes desactivar el silencio si quieres hablar verbalmente. Um, o si estás desconectado, eso también está bien. Entonces NX en sí es completamente gratis. NX cloud es la única parte de pago. Um, y, uh, sí. Um, si tienes, um, déjame señalar, um, algunas de las cosas de la community. Um, entonces, si te gustaría, um, chatear con otras personas que están trabajando en, uh, NX, o, o, ya sabes, tratando de usar NX, um, si vas a NX.dev, este enlace a la derecha aquí es el Slack de la Community. Um, y puedes seguir a la gente en Twitter. También publicamos muchos videos en YouTube, um, o simplemente, ya sabes, interactúa en GitHub también. Entonces, esta área aquí tiene todas nuestras áreas de community, uh, cosas de community. Um, sí, ha sido genial. Um, presentando con ustedes. Um, gracias, um, por su atención. Y, uh, hola a todos los que vuelven y ven esto más tarde. Um, buen, buen trabajo, uh, viendo todo el camino hasta el final del video. Muchas gracias. Sí, eres bienvenido. Eso fue genial. Muy bien. Gracias a todos. Adiós. Adiós.

Watch more workshops on topic

React at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
Featured WorkshopFree
Isaac Mann
Isaac Mann
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component

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

Levelling up Monorepos with npm Workspaces
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Levelling up Monorepos with npm Workspaces
Top Content
Learn more about how to leverage the default features of npm workspaces to help you manage your monorepo project while also checking out some of the new npm cli features.
End the Pain: Rethinking CI for Large Monorepos
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.
Federated Microfrontends at Scale
React Summit 2023React Summit 2023
31 min
Federated Microfrontends at Scale
Top Content
The talk will be a story of how Personio went from rendering through a Monolithical PHP architecture, to a microfrontend oriented Next JS app, powered by Module Federation and the NX monorepo toolchain.
Scale Your React App without Micro-frontends
React Summit 2022React Summit 2022
21 min
Scale Your React App without Micro-frontends
As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!
The Age of Monorepos
JSNation 2022JSNation 2022
25 min
The Age of Monorepos
The history of the web can be divided into evolutionary development leaps. The age of inline scripts, the age of jQuery, the age of SPAs, the age of JAMStack...We are now entering the next stage that has been carefully prepared in the past few years. Let me invite you to the world of modern monorepo solutions and share with you the benefits you will reap by using them in every project size and setup. It's time you automate those boilerplate tasks and reduce the bottlenecks so you can focus on what truly matters.Get ready for the next leap! Welcome to the age of monorepos!
Remixing Your Stack in a Monorepo Workspace
Remix Conf Europe 2022Remix Conf Europe 2022
22 min
Remixing Your Stack in a Monorepo Workspace
Remix entered the stage with a unique and refreshing take on how to develop on the web. But how do you integrate it into your existing ecosystem of applications? Do you want to test-drive Remix on a small project, or do you want to go full-in, but it is tricky to do a big-bang migration from your existing React app? In this talk, we're going to explore how a monorepo-based code organization can help integrate Remix with your existing React and TypeScript infrastructure, facilitating high code reuse and a migration path to Remix.