Masterclass de Node Monorepos con Nx

Rate this content
Bookmark
Github

El tener múltiples APIs y múltiples equipos en el mismo repositorio puede causar muchos dolores de cabeza, pero Nx tiene la solución. Aprende a compartir código, mantener archivos de configuración y coordinar cambios en un monorepo que puede escalar tanto como tu organización lo haga. Nx te permite dar estructura a un repositorio con cientos de colaboradores y elimina los retrasos en CI que suelen ocurrir a medida que el código base crece.


Tabla 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 - Agregar un CLI de Node

- Laboratorio 8 - Límites de módulos

- Laboratorio 9 - Plugins y Generadores - Introducción

- Laboratorio 10 - Plugins y Generadores - Modificar archivos

- Laboratorio 11 - Configuración de CI

- Laboratorio 12 - Caché distribuida

160 min
06 Apr, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Este masterclass explora Node Monorepos con NX, resaltando 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 el uso de bibliotecas, la configuración de límites de módulos, el linting y la integración de CI/CD. El masterclass también presenta NX Cloud, que ofrece caché distribuida y ejecución de tareas para mejorar el rendimiento. En general, el masterclass proporciona ideas prácticas y herramientas para el desarrollo y la ingeniería de software eficientes en un entorno de monorepo.

Available in English

1. Introducción a los Monorepos de Node con NX

Short description:

Bienvenido a los Monorepos de Node con NX. Este masterclass estará enfocado en el uso de Node como el framework con NX. NX es agnóstico en cuanto a framework y lenguaje, lo que te permite utilizar aplicaciones 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 una gestión simplificada de dependencias.

Muy bien, vale, así que bienvenido a los Monorepos de Node con NX. Esto es genial. Mi nombre es Isaac Mann. Soy arquitecto en NX. 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. Este masterclass estará enfocado en el uso de Node como el framework que utilizaremos con NX. Pero NX es, ya sabes, es prácticamente agnóstico en cuanto a framework y lenguaje. Pero profundizaremos más en eso. Por lo tanto, puedes utilizar aplicaciones front-end como React o Angular o cualquier otra tecnología front-end que estés utilizando. También puedes utilizar otros lenguajes como Java, Python y .NET con NX. Así que NX se trata de 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 comenzar con una pequeña discusión sobre por qué querrías un monorepo. Un monorepo es cualquier repositorio que tenga más de una aplicación viviendo en esa base de código. Entonces, ¿cuál es el beneficio de un monorepo? Hay tres categorías principales de beneficios para los monorepos. Los monorepos te brindan cambios atómicos, te permiten compartir fácilmente tu código y te ofrecen un conjunto único de dependencias, lo que facilita la gestión de esas dependencias. Así que vamos a profundizar en cada una de estas tres cosas y explicar

2. Beneficios de los Monorepos y NX

Short description:

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

lo que son y por qué son beneficiosos. Así que si tienes una aplicación y una especie de biblioteca que se utiliza en esa aplicación. Y si las tienes gestionadas en dos repositorios separados, digamos que haces un cambio en la biblioteca de interfaz de usuario (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 así: alguien hace un cambio en la biblioteca común de interfaz de usuario. Suben el commit, confirman la versión y en algún momento posterior alguien intenta usar esa nueva versión de la biblioteca común de UI en la aplicación de la página de inicio. Se dan cuenta de que hay un cambio que rompe la aplicación. Entonces, presentan un error con la biblioteca común de UI y dicen: `Oye, tienes que arreglar esto`. Y luego, más tarde, cuando el desarrollador de la biblioteca de 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 ver si eso soluciona su aplicación. Así que todo ese ciclo, por lo general, en el mejor de los casos lleva 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 que si pusieras tanto la biblioteca, la biblioteca y la aplicación juntas en el mismo repositorio, entonces ese ciclo sería, sería solo el creador de la biblioteca de UI haciendo un cambio, ejecutando las pruebas y viendo Oh, rompió las pruebas en la aplicación de la página de inicio, tengo que arreglar eso. Y eso, eso ciclo tomaría como media hora o una hora. Incluso antes de enviar una solicitud de extracción (PR), te darías cuenta de que rompiste la aplicación, tendrías que modificar tu código. Entonces, eso es, en una PR, sabes, tienes todos los cambios que necesitas hacer en la aplicación o los cambios que necesitas hacer en la biblioteca de UI para adaptarla a la aplicación misma. Ese es un beneficio de un monorepo. El segundo beneficio es el código compartido. Digamos que tienes alguna lógica sobre, ya sabes, qué es un nombre de usuario válido y tienes esta función, obviamente, en diferentes escenarios tendrías una función más compleja que esto, estás manejando si el nombre de usuario fue válido. Pero digamos que quieres compartir esto en toda tu aplicación, en varias aplicaciones, varias bibliotecas. Si esto cambiara alguna vez, tendrías que actualizar eso en cada repositorio que lo esté utilizando. Si estás copiando el código de un repositorio a otro, pero si estás en un entorno de monorepo, simplemente puedes usar esta función. Y cualquier cambio en esa función cambiará el comportamiento en todo el repositorio, donde se esté utilizando. Así que compartir código fácilmente. La tercera cosa es tener un único conjunto de dependencias. Si tienes un marco de trabajo como Node, o en este caso, y la imagen es react, si tienes diferentes versiones de ese marco de trabajo que se utilizan en diferentes aplicaciones, puedes encontrarte con errores extraños y difíciles de depurar en tiempo de ejecución. Y, tener tu código en el mismo repositorio básicamente te obliga a tener, bueno, puedes establecer reglas para obligarte a tener la misma versión para todo lo que está en ese repositorio. Es posible tener múltiples versiones en el mismo monorepo, pero es mejor tener una sola versión y facilitar las cosas a largo plazo. Así que básicamente, en un gran 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 tienes dos o tres aplicaciones que se trabajan tal vez una vez cada dos meses, inevitablemente se quedan atrás y tienes que recordar: `Ok, ¿cómo actualicé ese marco de trabajo?`. Hace seis meses actualicé, y tienes que recordar y pasar por todo ese trabajo nuevamente. Mientras que si estuvieras actualizando todas tus aplicaciones, las 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. Lo haces todo de una vez y es mucho más fácil que hacerlo distribuido a lo largo de un año o cada vez que pienses en actualizar esas aplicaciones. Muy bien, una forma de tener un monorepo, la diferencia entre un monorepo y la colocación de código y la colocación de código es cuando simplemente juntas todas las aplicaciones en el mismo repositorio sin tener ninguna herramienta para gestionarlo. Y eso puede ser una pesadilla. Si simplemente lo juntas todo, puedes terminar en una situación en la que estás ejecutando pruebas innecesarias y no tienes límites de código y todo el código se mezcla y es difícil de mantener. Y puedes tener herramientas inconsistentes donde hay conflictos entre cómo esas herramientas interactúan entre sí, como tus herramientas de pruebas o tus otras herramientas. Así que hablemos de ejecutar pruebas innecesarias. Digamos que tienes una biblioteca llamada la página de inicio de productos. Si hicieras un cambio solo en el proyecto de la página de inicio de productos, sabes que necesitas ejecutar las pruebas de ese proyecto para asegurarte de que no rompiste nada. Pero, sabes que no tienes que ejecutar las pruebas en la biblioteca de productos compartidos porque, sabes que no hay forma posible de que hayas roto las pruebas en la biblioteca de productos compartidos. Si lo único que cambiaste fue este proyecto superior. Entonces, si no tienes ninguna herramienta configurada en tu repositorio que entienda tu gráfico de dependencias, tendrías que ejecutar las pruebas para todo en tu repositorio. Cada vez que haces un cambio en cualquier parte de tu repositorio. Sería mejor tener alguna herramienta que entienda que solo necesito ejecutar pruebas en la página de inicio de productos, no en la biblioteca de productos compartidos. Y esto obviamente es un escenario muy simple, un repositorio real. Y este es incluso un ejemplo de un repositorio pequeño aquí, este ejemplo, un ejemplo más típico sería algo como esto, donde tienes muchos nodos diferentes y necesitas algún equipo para entender qué pruebas realmente necesito ejecutar en lugar de tener a una persona tratando de recordar todas estas diferentes líneas de gráficos de dependencias. Para saber que tienes que ejecutar estas pruebas y no estas pruebas. Quieres asegurarte de ejecutar todas las pruebas que necesitas ejecutar, pero no las pruebas que no necesitas ejecutar. Muy bien, número dos, sin límites de código. Si simplemente juntas todo, podrías tener algún código que escribas en tu biblioteca de interfaz de usuario (UI), que está destinado a ser utilizado solo por ti, para usarlo dentro de ese proyecto. Y no estás listo para que otras personas comiencen a usarlo todavía. No quieres mantener esa superficie de API. Pero no hay nada que impida a las personas acceder a tu proyecto y usar alguna función que solo quieres para ti. Pero ellos dicen: `Oh, hay código que me gusta, quiero usarlo`. Y ahora porque lo están usando, estás obligado a mantener esa API y no puedes cambiarla. Porque si la cambias, romperás su aplicación. Necesitas alguna herramienta configurada para decir: `Estas son las funciones con las que estoy bien si otras personas las usan, y estas son funciones que son puramente internas y solo para mis proyectos, para usarlas.

3. Beneficios de NX en Monorepos

Short description:

NX proporciona herramientas consistentes para gestionar la complejidad en los 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 basado en el 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, típicamente 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 en realidad 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. Muy bien. Así que necesitas algunas herramientas para ayudarte a gestionar esa complejidad. Eso es lo que NX puede hacer. NX es una herramienta que te ayuda a obtener todos los beneficios de un monorepo sin las desventajas de la colocación de código. Muy bien. NX te ofrece una ejecución más rápida de comandos. Entonces, los ejecutores son básicamente, ya sabes, scripts de NPM que pueden ayudarte a ejecutar, ya sabes, tu build y test y lint y todas las acciones que realizas 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, utiliza la versión en caché de esa salida y, ya sabes, sin ejecutar realmente el build nuevamente. Entonces, 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 de la 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. Entonces, ese mismo comportamiento de caché que obtienes en tu propia máquina, puedes compartir esa caché en toda tu organización. Entonces, si alguien en cualquier lugar ha ejecutado este comando con este mismo código, puedes usar su caché y reproducirla tú mismo. Esto es especialmente útil para las solicitudes de extracción (PR). 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 usar tu versión en caché en lugar de ejecutar ese mismo cálculo en su máquina nuevamente. Básicamente, solo ejecutas 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. Entonces, si tienes, ya sabes, una aplicación que depende de cinco bibliotecas diferentes, el paso de construcción de la biblioteca también se almacena en caché, al igual que 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 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 se exporte desde ese index.ts no se te permite acceder a ella y comenzar a usarla. Puedes configurar un sistema de etiquetas 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. Y luego estas bibliotecas se comparten y pueden ser utilizadas por cualquiera. 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 una revisión de un grupo determinado de personas si cambias el código dentro de esa área. Entonces, 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. Entonces, los complementos te ayudan básicamente para que no te preocupes 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, 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 para realmente ver, ok, cuál es la arquitectura real de mi código en lugar de la arquitectura que deseo que tenga mi código o la arquitectura que tenía mi código hace dos meses cuando alguien dibujó un diagrama. Entonces, 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á ahí, tú o algún arquitecto realmente deseaba que estuviera allí o pensaba 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 luego 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 configuración de TypeScript y luego configuras, ya sabes, rutas para tus bibliotecas para poder referenciarlas e importarlas en aplicaciones. Para todas las diferentes configuraciones que tiene NX, hay configuración a nivel de espacio de trabajo y a nivel de proyecto. La configuración a nivel de proyecto heredará la configuración a nivel de espacio de trabajo. Lo mismo ocurre, ya sabes, si tiene una configuración de TypeScript diferente que necesita, lo mismo ocurre con Jest y Prettier y todas las demás herramientas que NX puede configurar para ti.

Muy 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 poniendo tu código. Te dará el alias de ruta para importar código dentro de las cosas. Entonces, si configuras el nombre de tu espacio de trabajo como my org, tu directorio estará bajo my-dash-org, tu alias de ruta estará en my-org/whatever-project estás importando. Y luego, si alguna vez publicas tu biblioteca en MPM, el ámbito de MPM estará en my-org/whatever-library tienes. Cada una de estas tres cosas se puede cambiar después del hecho. Pero cuando configuras inicialmente tu espacio de trabajo, todo lo que escribas después de Create NX Workspace se establecerá en esas dos cosas. Muy bien. Así que vamos a comenzar con el laboratorio uno. Muy bien. Entonces, este repositorio aquí, no necesitas clonar este repositorio. Porque vamos a crear un repositorio completamente nuevo para el taller. 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. Muy bien. Voy a ejecutar NPX create NX workspace. Y lo vamos a llamar BG-Horde. Muy 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 agregan 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 agregar 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 en la carpeta apps.

Um, okay. ¿Sabes qué? Tengo una versión antigua de create INX 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 manera que quieras y NX se aparta de tu camino, a menos que hagas lo que quieras. Um, para nuestro, para nuestro, um, taller aquí, vamos a usar el integrado. Um, tiene una estructura de configuración con apps y libs, y es más, um, uh, es 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 lentes. Um, y luego, um, y está configurado para que puedas tener múltiples aplicaciones en el mismo repositorio, um, el, el, el, um, el, el, um, ya sabes, tú las últimas tres opciones, standalone react, Angular, no depth. 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 standalone, 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, taller, vamos a usar el repositorio de modelo integrado y luego hay varias otras opciones de aplicaciones aquí. Entonces, apps es, uh, básicamente, uh, una configuración mínima, um, react, Angular, todas estas opciones aquí abajo. Configuran, um, preconfiguran una, um, una aplicación para ti, pero vamos a, vamos a empezar desde cero y luego agregar lo que queremos aquí. Um, veamos, habilitamos el almacenamiento en caché. Vamos a decir que no por ahora. Más adelante, lo agregaremos. 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 de código separada. Sí. Ventana de código. Um, veamos. ¿Es lo suficientemente grande esta fuente? Déjame probar eso. De acuerdo. De acuerdo. Um, esto es lo que genera. Tienes una carpeta de apps y libs. Um, tienes NX.JSON, en el que profundizaremos un poco más tarde. Y en tu package.json, solo tienes NX y neural workspace. De acuerdo. Um, de acuerdo. Así que esa es solo la configuración inicial. Ahora déjame volver a mis diapositivas aquí. Y tenemos un poco más, un poco más de explicación que hacer. De acuerdo. Así que estos primeros laboratorios tienen muchas, muchas diapositivas que los acompañan, pero más adelante haremos más trabajo práctico aquí. De acuerdo. Entonces, 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 agregan otra capa encima de eso, 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 dan algunos, um, generadores de código para automatizar algunos de los procesos de desarrollo repetitivos. Entonces, 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 community y plugins oficiales de NX que puedes agregar si quieres. Um, para agregar un plugin, simplemente lo instalas con NPM o con Yarn y luego, um, y luego estará disponible para ti. Um, uh, entonces, 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. Entonces, para el plugin de Angular, haces NXG generate, um, at NARL slash 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 para VIM. Um, VIM no es tan completo en esto porque obviamente VIM no tiene una interfaz de usuario, pero hay características de tipo IntelliSense que, que vienen con VIM. Um, entonces, 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 agregar o construir sobre los generadores proporcionados por NX desde un plugin, o puedes, um, ya sabes, construir tus propios generadores desde cero diciendo, Hola, crea este archivo y, y mueve este, uh, este código de esta manera. Um, y en lugar de tener una lista de tareas en un archivo README que tiene 10 pasos, simplemente tienes un generador que dice, okay, ingresa el nombre del nuevo componente que estás haciendo y, o la nueva ruta que estás haciendo. Y luego todo se configura de la manera que se supone que debe ser. De acuerdo. Um, no es una aplicación de Angular, pero está bien. Entonces, en el paso dos del laboratorio dos, vamos a hacer una, una API de Node aquí. Cuando esto termine, la estructura de archivos se verá así. Tendremos una aplicación de API en la carpeta apps. De acuerdo. Así que hagamos, veamos si tengo suficiente espacio en la pantalla para hacer esto lado a lado. Entonces, si ejecuto NX --version, uh, ¿qué está pasando aquí? Déjame ejecutar npm install. Veamos qué pasa aquí bamboo. De acuerdo. De acuerdo. 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. Intentemos esto. No. Intentémoslo aquí. No existe el archivo o directorio. De acuerdo. 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. De acuerdo, ahí vamos. Bien. De acuerdo.

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

Short description:

Hubo algo extraño con mi terminal, pero ahora está mejor. Podemos usar cualquier versión de Node que queramos. Los generadores personalizados aparecen en la consola de NX. Podemos agregar plugins usando el comando NX list. Agregamos el plugin de node y Express. Usamos el plugin narwhal-node para generar una aplicación de Node llamada API. Actualizamos el archivo main.ts y agregamos endpoints. Para servir la aplicación, podemos usar el comando NxServe. Solucionamos un error agregando otro archivo. La API está funcionando y hemos realizado nuestros cambios. Creamos una nueva aplicación rápidamente sin preocuparnos por la configuración.

Hubo algo extraño con mi terminal, pero ahora está mejor. Estoy usando Node 18, pero puedes usar la versión que desees.

Sí, buena pregunta. Naya Kunin pregunta, ¿los generadores personalizados aparecen en la consola de NX? Y la respuesta es sí. Consola de NX. Llegaremos a esto un poco más tarde. Pero haces clic en generar aquí. Y esto busca en tu repositorio y encuentra todos los generadores. En este caso, solo tenemos nuestro espacio de trabajo instalado. Más adelante, cuando agreguemos otras cosas, habrá otras cosas en esta lista. Y si agregas tu propio generador personalizado, también aparecerá en esta lista. Cualquier opción que configures para tu generador aparecerá aquí como campos que puedes completar y luego haces clic en ejecutar y aparece. Sí. De acuerdo, genial. Muy bien, entonces. NPX next hacemos esto. OK, así que hagamos un X list para ver qué plugins tenemos, y esto genera una gran cantidad de código aquí. Voy a hacer un X list. ¿Cuál es el comando o es? Configuraciones No. Un X list menos. Pipe a less. Ahí vamos, esto es solo la parte superior aquí, así que muestra lo que está instalado. Solo se ha instalado un X, y tenemos todos estos plugins disponibles para nosotros. Estos son los plugins oficiales de NX. Y luego hay una lista completa de plugins de la comunidad, con una breve descripción para cada uno de ellos. Y hay muchos aquí. Entonces, lo que queremos agregar es el plugin de node, así que haremos NPMI-D, narwhal-node, y también agregaremos Express. Porque usaremos Express. Estos son los pasos tres y cuatro aquí. Ahora vamos a pasar al paso cinco, y usaremos el plugin narwhal-node para generar una aplicación de Node llamada API. Usaremos esa sintaxis de generador, nxg at 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. Si quisiéramos usar la NxConsole para esto, así sería la línea de comandos. Así que puedo usar NxConsole aquí y ejecutar generar, y ahora en lugar de tener solo el espacio de trabajo de narwhal, también tenemos narwhal-node y las dependencias narwhal-node, el linter y JavaScript. Entonces, narwhal-node crearía una aplicación aquí, y hay varias opciones entre las que podemos elegir, lo único que queremos ahora es establecer el nombre en API. Y hace una simulación de esto. Y luego hagamos clic en ejecutar aquí, y crea una serie de archivos, actualiza nuestro package.json y actualiza NX, así que veamos los cambios que hizo. En package.json se actualizó, solo se formateó, supongo, agregó algunas dependencias de desarrollo para configurar node para nosotros, agregó Axios y TSLib, agregó ESLint para el linting, Prettier para el formato Jest, así que todo esto se configura para nosotros creó una aplicación API con algunas opciones de configuración y una aplicación de extremo a extremo para probar, para ejecutar pruebas de extremo a extremo en esta API de Node. De acuerdo, main.ts es un poco nuestro punto de entrada aquí. Y project.json aquí es la configuración que controla cómo se ve la compilación y cómo se ve el servicio y el lint y las pruebas. Y así podemos ver aquí en la consola de NX aquí, si miramos debajo de API aquí, podemos ejecutar compilación, servicio, lint y prueba. Entonces, si ejecutamos compilación aquí, la compila y si ejecutamos servicio, lo lanza en modo de lavado. Y también podemos hacer lint y probarlo. Permíteme volver al laboratorio aquí. Muy bien, así que vamos a actualizar el archivo main.ts para agregar algunos endpoints aquí. Así que no estamos realmente haciendo, esto no es un taller de Node. Así que vamos a copiar y pegar el código aquí. Esto está usando express y configurándolo para nosotros. Y aquí lo hemos hecho.

De acuerdo, ahora para servir la aplicación, podemos ejecutar. Entonces, podemos usar la NxConsole o simplemente podemos ejecutar NxServe API. Oh. De acuerdo. Hay un error en el código que copié. De acuerdo. Main.ts. Creo. Hay otro archivo que necesita ser importado. Sí, hay otro archivo que debo agregar. Quiero ver dónde lo agregué. Aquí está, este. Games.repository.ts. Así que debajo de esto, necesito crear una nueva carpeta, app, y un nuevo archivo, games.repository. Sí. Pegar eso. Y guardarlo. Y luego volveré a ejecutar la búsqueda. De acuerdo, ahora está bien. Ahora, si vamos a localhost333 api, barra diagonal juegos. Lo siento, déjame mover esto aquí. Este es el JSON que esperamos ver para la API. Muy bien, esta es la emoción del desarrollo backend. Ves un poco de JSON y estás feliz. Pero los desarrolladores frontend estarán muy contentos de ver ese JSON. Genial, vamos a volver. De acuerdo, eso funciona. Y ahora vamos a confirmar nuestros cambios. Llamémoslo laboratorio dos. Y eso funciona. De acuerdo, así que lo que hicimos aquí es crear una aplicación completamente nueva. Y nos llevó muy poco tiempo ponerla en marcha. Podríamos crear cinco aplicaciones más en otros cinco minutos si quisiéramos. Así que nos preocupamos por el contenido de nuestro código en lugar de preocuparnos por la configuración. Muy bien, pasemos a la siguiente diapositiva. ¿Preguntas sobre eso rápidamente? Déjame ver, buscar en Discord. De acuerdo, 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, linting y pruebas. Los ejecutores se definen para cada objetivo y se pueden cambiar fácilmente por 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 es bueno. Ver, ¿todavía tenemos 32 personas? Sí, tenemos, sí, aproximadamente el mismo número. Genial, bien. Vamos a volver a Keynote aquí. Muy bien, hablemos de los ejecutores. Así que te mostré brevemente 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 construcción, servicio, linting y prueba, o cualquier otro nombre que desees. Si tienes generación de documentación, podrías tener un objetivo de documentación. Cada objetivo de prueba tiene un ejecutor definido para él. Si es un complemento, entonces tiene, ya sabes, Narwal Jest y luego el nombre del ejecutor. Narwal Jest es el nombre del complemento y luego dos puntos, el nombre del ejecutor en este caso, que es simplemente Jest. Así que tenemos, déjame mostrarte rápidamente. En nuestro caso, tenemos nuestra construcción y luego el ejecutor. Narwal esbuild, por lo que está utilizando 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 a JavaScript, podrías ejecutar el TSC, o si quisieras cambiar a SWC, podrías hacerlo, y luego hay opciones para cada uno de ellos. Así que las opciones obviamente cambiarán para cada ejecutor para configurarlos de diferentes maneras. Estas, en este momento, son las opciones para esbuild. Pero puedes cambiar fácilmente qué ejecutor estás usando para hacer cosas como construir, servir, o probar, o lo que sea. Así que si volvemos aquí. Muy bien, eso es el ejecutor.

7. Ejecutando Ejecutores y Configurando Objetivos

Short description:

Para ejecutar un ejecutor, usa nx run o nx console con el nombre del proyecto y el objetivo. También puedes usar nx serve o nx build con la notación abreviada. Las opciones se pueden especificar después del nombre del objetivo. El nx console proporciona opciones predefinidas desde el archivo project.json. Al ejecutar nx build API, se agrupan todos los archivos TS en un solo archivo JS. La opción de agrupamiento 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.

Para ejecutar un ejecutor, puedes usar nx run, y luego el nombre del proyecto que es API, y luego el objetivo que será serve o build, y luego cualquier opción que venga después. Así que por ejemplo, nx run MyAppServe, o para la notación abreviada, podrías tomar el nombre del objetivo y ponerlo al principio. Así que nx serve MyApp, o nx serve API, o nx build API, y luego las opciones vienen después. Esto funciona para cualquier nombre de objetivo y cualquier nombre de aplicación.

Lo mismo, también puedes ejecutarlo con nx console, y te mostrará todas las opciones como campos rellenables aquí. Muy bien, vamos a probar eso. Si vamos aquí al laboratorio tres. Tenemos ejecutores. 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. Muy bien, así que servir la aplicación era nx serve API. 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. Puedo hacer clic aquí y simplemente hacer clic en ejecutar aquí, así que se ejecutará sin darme el formulario, pero voy a ir a construir aquí y hacer build API. Y esto me da muchas opciones aquí. Estas ya están predefinidas. Estos son los valores que están en el archivo project.json. El archivo main.ts está aquí. Así que eso es lo que está predefinido aquí. Me muestra el valor predeterminado que está lleno en el archivo project.json, pero si quieres cambiarlo, puedes hacerlo aquí y luego ejecutarlo en otro lugar. Parece que esto es un error de NxConsole aquí. Interesante. Pero vamos a intentar ejecutar esto. Y lo construyó y lo colocó en la ruta de salida que definimos aquí. Así que dist apps API. Así que dist apps, dist apps API está aquí. Y este es nuestro, este es nuestro resultado. Muy bien, así que lo construimos. Así que pusimos cosas en la carpeta dist. Vamos a ver en apps API proyectos en Asan, y tiene una opción ejecutiva allí. Y queremos cambiar esto para que sea minificado. Así que para agrupar todo. Así que en lugar de decir bundle false, digamos bundle true. Y veamos qué hace eso en la salida. Así que si ejecuto NX, NX build API de nuevo. Así que ahora si miramos en 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. Esto tiene, ¿cuál es el tamaño de esto? Oh, no sé, 23,000 líneas de código aquí, mientras que si voy a project Json y establezco esto en false, ejecuto esto de nuevo, ejecuto esto de nuevo, aquí este archivo main.js tiene solo 36 líneas de código. Y luego está el repositorio de juegos y eso es todo. Así que esa es la diferencia. Así que puedes establecer eso en el archivo project.json o también puedes establecerlo desde la línea de comandos. Puedes hacer dash-bundle equals true aquí y eso lo agrupará en un solo archivo como este. Muy bien. Así es como puedes establecer cualquier bandera que desees en tu ejecutor. También puedes obtener. Vamos a ver. Muy bien. Parece que el autocompletado no está funcionando en este momento para Nx console. Eso está bien. No. Muy bien. Vamos a ver. Así que hemos establecido bundle en true. Instruimos al ejecutor para agrupar todos los archivos TS en un solo archivo JS, lo cual hicimos. El serveTarget utiliza el buildTarget. Así que esta construcción tiene opciones aquí. Vamos a cerrar esto. Así que serveTarget aquí abajo tiene un buildTarget de API build. Básicamente, lo que esto hace es decir, primero construye esta aplicación utilizando lo que está definido aquí arriba, y luego ejecuta node en la salida de eso. Eso es todo lo que hace serve. Así que si quieres cambiar esto y hacer, así que puedes tener una versión de desarrollo y una versión de producción. Esto simplemente ejecuta la construcción con la configuración de producción, que está configurada aquí, y luego este serveTarget, sirve con la configuración de desarrollo, ejecuta la construcción para desarrollo y luego ejecuta node en ella. Así que si quieres establecer el NxBuild API, si quieres establecer la configuración en producción manualmente, puedes hacerlo así, o puedes establecerlo en desarrollo de esta manera. Ve a la izquierda, y de esta manera, tal vez sea configurar, lo siento. Creo que tienes que escribir la configuración completa. Ahí vamos. Eso lo ejecutó con desarrollo. La configuración predeterminada aquí es desarrollo, y para construir, la configuración predeterminada es producción. Así que puedes cambiar eso, estos nombres son totalmente arbitrarios, así que puedes establecerlos como quieras.

8. Configuración de Configuraciones y Creación de Bibliotecas

Short description:

Puedes configurar diferentes tipos de configuraciones y sobrescribir opciones en archivos de configuración. Janet pregunta sobre el uso de la versión global o NPX. NX puede usar cualquiera de ellos, 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 se pueden implementar o ejecutar directamente. NX opera a nivel de biblioteca o aplicación. Dividir el código en bibliotecas permite un mayor almacenamiento en caché e infraestructura. El gráfico de dependencias se basa en proyectos. 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 crear una biblioteca.

Entonces, así es como puedes configurar diferentes tipos de configuraciones. Cada opción debajo de producción es la misma. Todas estas opciones se pueden sobrescribir en estos archivos de configuración. Lo que hace es tomar todo lo que está debajo de opciones y mantenerlo igual, excepto lo que se especifica aquí. Simplemente sobrescribe estas opciones de ESBuildOptions y establece SourceMap en false y OutExtensions en lo mismo. Así que simplemente sobrescribe SourceMaps para que sea false en lugar de true. Pero si necesitaras cambiar algo más, podrías cambiar algo más.

Janet está preguntando si se debe usar la versión global o usar NPX. Me gusta usar directamente NX. Si usas NPX-NX, también está bien. NX usará automáticamente la versión que se establezca en tu package.json. Entonces, si tengo un NX global de... Ahora mismo, la versión instalada localmente es 15.9.2. 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... Tal vez después de hacer NX-V. Aquí dentro de bg-hoard es 15.9.2. Si salgo de aquí, NX-V, aún no le gusta. Bueno, bueno... Sí, así que dice que no puede encontrar la versión global, lo cual es extraño porque definitivamente estoy usando NX globalmente. Pero NX simplemente usará lo que se ejecute localmente. Lo que esté dentro de esta carpeta. Construye para la línea de comandos. Alguien está llamando... Ah. Muy bien, así que voy a repasar las diapositivas y luego Get little tech. Tal vez puedas compartir tu pantalla mientras las personas trabajan en el Laboratorio 4. Porque me intriga por qué no está funcionando para ti. Así que voy a hacer algunas diapositivas para el Laboratorio 4. Y luego... Ok, hasta ahora, lo único que hemos hecho es crear una aplicación. Hemos pasado una hora, ok, estamos bien. Hasta ahora, solo hemos creado una aplicación. A continuación, vamos a crear una biblioteca. 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 implementadas. Podrían ser publicadas en npm para ser utilizadas fuera del repositorio, pero además de eso, se espera que el código se utilice en lugar de implementarse directamente. Mientras que las aplicaciones se pueden implementar en algún lugar o ejecutar directamente. Eso es lo que es una aplicación. Por lo general, puedes tener bibliotecas que son características como una ruta en una aplicación de front-end o que se centran en la interfaz de usuario o en los datos, o simplemente son bibliotecas de utilidades de nivel inferior. Puedes hacer las bibliotecas tan granulares como desees. Pero NX opera a nivel de biblioteca o aplicación para cada proyecto. Si deseas utilizar más la funcionalidad de almacenamiento en caché de NX, ayuda dividir las cosas en más bibliotecas. Las bibliotecas pueden tener básicamente la estructura de directorios que desees. Puedes tener una carpeta, puedes agruparlas dentro de carpetas. No es necesario que estén dentro de la carpeta libs, pero eso es lo que se establece de forma predeterminada en esta configuración del taller. Así que puedes tenerlas en el nivel raíz si lo deseas o puedes cambiar el nombre de la carpeta libs a algo más. Puedes llamarlas paquetes o bibliotecas o cualquier nombre que desees. Por lo general, para las grandes organizaciones, para cada aplicación, generalmente tienes una carpeta dentro de la carpeta libs. Las bibliotecas específicas de esa aplicación se colocarían en esa carpeta. Entonces tendrías algo como libs/API y luego libs/front-end o libs/store si tuvieras una aplicación de almacenamiento, como una aplicación de front-end. Y luego tendrías una carpeta libs/shared donde vivirían las bibliotecas que se pueden utilizar en varias aplicaciones. Básicamente, toda esa estructura depende de lo que tenga sentido para tu código. En general, cuanto más dividas el código en nuevas bibliotecas, más te ayudará el almacenamiento en caché y la infraestructura de índices. Pero hay un costo al crear una nueva biblioteca. Es otro lugar donde se separa el código. Así que debes saber cómo agrupar el código que tiene sentido estar junto. Pero si es, los mismos pros y contras que dividir el código en carpetas separadas o dividir el código en archivos separados o componentes separados. Es lo mismo con las bibliotecas. Definitivamente puedes exagerar en uno u otro lado. Simplemente, y siempre puedes volver atrás. Si tienes una biblioteca que es demasiado grande, puedes dividirla. Si tienes demasiadas bibliotecas, puedes combinarlas nuevamente. Así que tu gráfico de dependencias se basa en un proyecto. Cada biblioteca o aplicación es un nodo en el gráfico de dependencias. Y eso es lo que tenemos para las bibliotecas. Muy bien, así que déjame volver y responder algunas de estas preguntas en Discord aquí. Vi que Toon está preguntando, ¿puede NX llamar a los scripts de package.json? Sí, sí puedes. Este taller te muestra un repositorio de estilo integrado que utiliza Project JSON. Pero si tuvieras, déjame mostrarte rápidamente aquí. Veamos, archivo, package.json y package.json predeterminado. Eso está bien. Creo que quiero llamar a esto. Creo que se confundirá si el nombre no coincide. Scripts. Entonces, si... Project JSON es opcional. Puedes tener solo un package.json en lugar de un project.json, y entonces, veamos, o podrías tener ambos. Entonces digamos, llamar a esto hello y diremos echo hello world. Hagamos hello desde package.json. Entonces, si ejecuto nx hello, porque hello es el nombre del script aquí, nx hello y luego API es el nombre del proyecto. Ejecutará hello desde package.json. Entonces, lo que pongas aquí, se ejecutará para ti. Así que sí. Y luego hubo otra pregunta. Y luego, sí, Get little tech. ¿Te gustaría compartir tu pantalla y mostrarnos qué está pasando con tu VS code? Para todos los demás, siéntanse libres de comenzar con el laboratorio, laboratorio cuatro, creo que es en lo que estamos, el siguiente. Sí, laboratorio cuatro, donde estamos creando una...

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

Short description:

En el laboratorio cuatro, nos adentramos en las migraciones y la actualización de dependencias. Agregamos una versión antigua de NX Workshop node y luego realizamos la migración a la última versión. 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 de todos los laboratorios hasta un paso específico. Sin embargo, puede haber algunos problemas con el proceso de migración que deben resolverse. También podemos ejecutar pasos de laboratorio específicos comentando el código innecesario en el archivo migrations.json.

Oh, en realidad el laboratorio cuatro es, si te quedas atascado, así que continuaremos con esto. De acuerdo, has hecho clic en ejecutar. ¿Qué sucede cuando haces clic en ejecutar? No aparece nada. Sí, exactamente. Parece que no funciona, pero tal vez no lo hace. Intenta hacer clic en construir en la parte inferior, debajo de generar y ejecutar objetivo. De acuerdo, haz clic en super node y luego haz clic en ejecutar aquí. ¿Funciona? No funciona, pero en realidad se ejecutó desde la terminal. De acuerdo. No sé. Sí. Puedo resolverlo más tarde. Sí, está bien.

Y Jannik pregunta, 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 agregando 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. Permíteme repasar el Laboratorio 4 aquí. El Laboratorio 4 se adentra en las migraciones. Y también, si necesitas saltar a una sección específica de la arquitectura del taller en la que te quedaste atascado, puedes saltar a ese paso. Una de las cosas que te ofrecen los complementos de NX es la capacidad de actualizar automáticamente tu código y tus dependencias. Y luego actualizar tu código para tener en cuenta los cambios que podrían haber ocurrido. Lo que vamos a hacer es ejecutar, vamos a agregar NX Workshop node, 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. De acuerdo, esta es una versión antigua de NX Workshop node. Podría ser cualquier complemento que tengamos. Así que eso en narwhal, en narwhal/node o en narwhal/react o cualquier complemento que estés usando. Permíteme eliminar este archivo package.json aquí. Y bien, hemos agregado esto. De acuerdo, y luego vamos a confirmar nuestros cambios aquí, solo para asegurarnos de tener una configuración limpia aquí. Y luego vamos a migrar a la última versión de NX Workshop node. Entonces, NX tiene el comando NX migrate en narwhal nx. Entonces, si simplemente haces NX migrate latest, eso migrará NX en sí y cualquier complemento que esté instalado. Así que si ejecuto eso, eso hará básicamente todo. Y veamos qué se actualizó. Todos estos ya están actualizados. Y todo lo que hice fue darle formato. Veamos, NX Workshop node está ahí. Así que hagamos NX migrate narwhal NX workshop node. Eso debería encontrar la versión 1.0.0. Verifiquemos eso. Veamos si lo comprimo manualmente. De acuerdo, ahí vamos, así que lo encontró. De acuerdo, creo que parte del problema allí por qué no estaba funcionando como esperaba es cuando configuré el taller, publiqué primero la versión 1.0 y luego la 0.0.1 más tarde. Normalmente solo dirías NxMigrate y encontrará la última versión. Lo que hizo es actualizar, ¿por qué no se actualizó entonces? De acuerdo, por lo general, lo que hará es actualizar esto. Oh, ya veo, lo actualizó. Simplemente no lo vi, ahí vamos. 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 estos son todos los generadores de código que se necesitan para avanzar a esa versión, esa siguiente versión. Y estamos usando una versión Frankenstein de esto. Por lo general, esto sería como modificar tu código para hacer cualquier cambio que rompa básicamente esa dependencia. Pero en nuestro caso, lo que está haciendo es que cada uno de estos generadores está completando el paso para cada laboratorio. Entonces 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á al laboratorio tres y cinco y hasta el laboratorio 13 aquí. Entonces, si ejecutáramos todo esto, puedes ejecutar nx migrate --run-migrations. Así que eso ejecuta todos estos pasos de configuración. Oh no. Eso no lo hace, tiene un 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, solo ejecuta npm i. Mm. De acuerdo, um. Hay algo mal con mi migración, así que simplemente voy a ejecutar. Simplemente instalé eso. No hay razón para que eso esté allí, um, pero solo para avanzar, vamos a ejecutar esto. De acuerdo. Sí. Uh, de acuerdo, así que esto recorrió todos los pasos hasta el laboratorio ocho donde se detuvo. Me quedé atascado en algo, pero puedes ver que aquí hizo muchos cambios, agregando algunas aplicaciones y um agregando algunas bibliotecas aquí. Así que esto es todo lo que aún no hemos abordado. Um, así que si quieres ejecutar hasta el laboratorio tres aquí, voy a comentar eso aunque no sea válido. Jason. Um, voy a ejecutar esto de nuevo. Así que esto solo ejecutará los laboratorios uno, dos y tres y nos llevará de vuelta al lugar donde se suponía que debíamos estar. Mmm. De acuerdo. Permíteme eliminar esos. Muy bien. Nx console tiene un estado obsoleto. Voy a ejecutar el comando run. Nx G rm cli bansheet e.

10. Creación de una biblioteca con NARL JS

Short description:

Vamos a crear una nueva biblioteca llamada off utilizando el complemento 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 generate con la bandera NXG y especifica el complemento 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 se producen cambios importantes. Es importante confirmar 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.

Quita eso. Y quita la biblioteca de la interfaz de mootle. Y. Y estamos de vuelta. De acuerdo. Esto nos preparó 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 complemento del taller. El complemento del taller de NX y el taller de NX no para completar los laboratorios. Y quiero completar el laboratorio cinco. Así que si completo el laboratorio cinco, puedes hacer un rango o puedes completar completamente el laboratorio. Voy a ejecutar eso. Y lo que hace es actualizar mis migraciones como archivo Jason para tener solo la finalización del laboratorio cinco aquí. Y luego puedo ejecutar nx run migrations aquí, ejecutar eso y eso completará solo el laboratorio cinco. La idea aquí es que esto te ayuda a mantener tu repositorio actualizado. Básicamente, el mantenedor de la biblioteca puede escribir estos scripts de migración. Entonces, cuando saben que están haciendo un cambio importante, pueden decir aquí, cualquier persona que esté usando esta biblioteca, ejecute este script de migración. Y, y, puedes actualizar sin necesidad de conocer todos los detalles minuciosos de los diferentes cambios de API que están ocurriendo. Esto creó una nueva biblioteca que vamos a hacer en el próximo laboratorio. De acuerdo. Permíteme volver aquí. Comencemos a generar una versión, luego cambiamos algunas cosas a mi gusto y luego actualizamos. Entonces, para nuestro caso, el, el taller de NX node, estos scripts de migración, el primero, completar el laboratorio uno va a restablecer todo, eliminar todo tu código básicamente, y luego, y luego comenzar desde cero. Y luego comenzar desde cero. Entonces, si tienes código que no deseas actualizar, no deseas que se elimine, entonces no ejecutes estos scripts. O podrías intentar ejecutar solo el siguiente laboratorio. Y eso solo intentará agregar. Código. Y siempre, si no te gusta lo que ha hecho un generador, asegúrate de confirmar antes de ejecutarlo. Y luego siempre puedes revertirlo aquí con tu historial de git. Ahora eso siempre es una buena práctica cuando ejecutas un generador, asegúrate de tener un historial limpio y bueno y luego ves lo que hizo y luego puedes deshacerlo si es necesario, de acuerdo. Muy bien, sigamos adelante. Hagamos, hagamos un laboratorio más y luego haremos un descanso. Piénsalo, tal vez un descanso de 10 minutos. De acuerdo. Bien. Así que hagamos el, um, Veamos, ¿tenemos eso para? De acuerdo. Tengo curiosidad si hay alguno, no. De acuerdo. Parece que estamos haciendo diapositivas. Bien. Bien. Hemos terminado con las diapositivas. Vamos a hacer el siguiente, el siguiente laboratorio. De acuerdo. Hasta ahora solo hemos creado aplicaciones. Um, a continuación, vamos a crear una biblioteca. Um, digamos que tenemos una aplicación de API. Tenemos alguna autenticación que debemos hacer y queremos que sea una lógica reutilizable. Um, entonces, esta autenticación. Cualquier lógica de autenticación que estemos haciendo, um, la vamos a mantener dentro de una biblioteca. Y, um, y luego vamos a utilizar ese código en la aplicación. Um, así que este es un buen momento para responder la pregunta de Jenick. Um, ¿diferencia NX entre bibliotecas y aplicaciones? Um, la única diferencia, um, básicamente, no. Um, básicamente son lo mismo. Um, la principal diferencia es para los usuarios de tu aplicación de tu base de código. Um, así que es útil poder ver esto, esto es como el punto de entrada para nuestro, um, donde está la base de código. Como si quisieras entender a grandes rasgos qué está pasando en esta base de código, miras en la carpeta de aplicaciones y ves, sabes, todo lo que se puede implementar. Y eso es como una comprensión a grandes rasgos de lo que está pasando. Um, puedes hacer, um, bibliotecas que tengan un objetivo de servir. Um, puedes hacer, um, obviamente puedes hacer, tener un objetivo de construcción en bibliotecas. Incluso puedes tener un objetivo de despliegue en bibliotecas para hacer todo lo que puedes hacer con una aplicación. También puedes hacerlo con bibliotecas. Um, pero típicamente, um, las aplicaciones están en la parte superior de tu, aún no lo he mostrado. Permíteme mostrar el rascacielos de NX aquí. Típicamente, las bibliotecas están en la parte superior de tu. Um, de tu, tu gráfico de dependencias. Acerquémonos un poco. Um, así que API está aquí en la parte superior y luego la biblioteca API auth que vamos a crear, um, está en la parte inferior. Estas cosas las haremos más adelante. Um, pero, um, tú sabes, incluso en el gráfico aquí, tienen el mismo símbolo. Um, así que básicamente, puedes tratarlos como lo mismo. Sí, básicamente las aplicaciones tienen puntos de entrada. Um. De acuerdo. Bien. Sigamos adelante. Um, para hacer una biblioteca de JavaScript simple, vamos a usar el paquete NARL JS, el complemento NARL JS. Y, uh, eso ya estaba instalado porque instalamos el complemento NARL node y NARL node depende de NARL JS. Así que ya deberías tener NARL JS disponible para ti. Permíteme deshacerme de estos. Gracias por las cosas. Esas no necesitan estar ahí. Um, y, entonces, vamos a hacer una nueva biblioteca y la vamos a llamar off. Para generarla, vamos a usar el comando generate de nuevo. De acuerdo. Con esa NXG, um, así que el complemento que vamos a usar es NARL JS. Para saber qué, um, qué complemento usar, um, voy a ejecutar generate aquí.

11. Creación y Uso de Bibliotecas

Short description:

Hay dos tipos de bibliotecas disponibles: JS y node. JS es para JavaScript de bajo nivel que se puede utilizar 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 de autenticación de la API se crea y se copia en la carpeta API. Se crea el punto de conexión 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 de autenticación de la API. 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.

Hay dos tipos diferentes de bibliotecas disponibles para nosotros. Pueden ser JS o node. JS es para JavaScript de bajo nivel que se puede utilizar en un contexto de nodo o en un contexto de front-end. Por otro lado, node se utiliza para cosas específicas de nodo. Las cosas de nodo pueden usar JavaScript, React, Angular, cualquier cosa escrita en JavaScript para usar una biblioteca de JavaScript simple, mientras que node sería específico para nodo.

Para crear una biblioteca de JavaScript, utilizaremos NXG de Narwhals, que es JS y lo llamaremos. Utilizaremos el generador de bibliotecas. Y llamaremos a la biblioteca 'off'. Escribiré aquí. ¿Qué prueba unitaria quieres usar? Supongamos que usaremos Jest, pero puedes usar V tests si quieres. ¿Qué empaquetador dirías? Supongo que TSC. Pero puedes probar y usar lo que quieras allí. ¿Por qué tan serio? Mencionaste que tu archivo migration.json no se ha creado. Eso significa que debes ejecutar el comando NX migrate. Este es el comando NX migrate. Puedes decir 'migrate latest' o 'migrate NX migrate at Narwal NX workshop node' y '1.0.0' para crear tu archivo migrations.json. Bien. Hemos creado la carpeta 'off'. Oh, sabes qué, cometí un error aquí. De hecho, ya lo hemos creado. Pero queremos que esté dentro de la carpeta libs API. Así que vamos a mostrar cómo eliminar una biblioteca después de haberla creado. Podrías simplemente eliminar esta carpeta, pero el problema con eso es que NX también ha creado otra entrada aquí. Y potencialmente ha modificado algunas otras configuraciones con esa biblioteca. Así que si solo eliminas la carpeta, tendrás configuraciones innecesarias en otros lugares. Para eliminarla, hay un generador de eliminación en el espacio de trabajo de Narwhal. Puedes usar 'R.M.' o 'remove'. Pero también puedes omitir completamente el complemento. Y si no hay, entonces no puedes hacer esto. Bueno, podrías hacer esto. Lib. Si ejecutas 'NXT lib', te permite elegir qué biblioteca quieres. Pero como solo hay un generador de eliminación, sabe exactamente cuál quieres. Así que si hacemos 'NXT lib' y queremos establecer la bandera '--directory' aquí, establece 'API' y el nombre, que lib es el que queremos llamar, que lib es el que queremos llamar para el icono. Y el nombre de la bandera del directorio es el que queremos usar para establecer la respuesta. Así que no tienes que volver a escribir el comando. Para que se vea igual, solo puedes escribir 'off'. Otra cosa que puedes hacer es 'API/off' así, y luego sabe que los directorios son API, y te pregunta qué tipo de biblioteca quieres. Diré JS y todo esto. 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 para completar el laboratorio cinco, 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. Esto es lo que se ha copiado. Y luego para usarlo en tu punto de conexión de autenticación de la API, así que aquí arriba, en api.src.main.ts. Aquí. Este punto de conexión de autenticación se crea. Esto tiene un error porque necesitamos actualizar nuestro, necesitamos volver a ejecutar TypeScript, reiniciar el servidor TypeScript. Cada vez que se actualiza 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 solucionó rápidamente. Así es como importa la función doAuth de nuestra biblioteca. Se define aquí en API auth, y se exporta aquí en index.ts, se dice que todo lo que está en API auth se exporta y se dice que está disponible pero para ser utilizado. Si comentara esto, entonces esto fallaría porque está diciendo, Hola, no puedo exportar nada. Así es tu API pública para tu biblioteca. Bien, ¿qué sigue? Y luego vamos a lanzar el gráfico del proyecto. Así que hagamos, si alguna vez NX está confundido acerca de algo, puedes hacer NX reset, que básicamente le dice que recalcule. Bien, hagamos esto. Ejecuté un NX graph. Y aquí tenemos nuestra aplicación API y la biblioteca API auth. 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, ¿ok, por qué hay una dependencia circular? ¿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. Ok. No cambié ningún archivo project JSON o no le dije a NX que la API depende de la biblioteca Auth. Todo lo que hice fue escribir mi código. Y si alguien más más adelante viene y elimina esta línea de código, entonces volvemos a ejecutar NXGraph. Ok. Tengo que hacer un reset aquí. Hay algunos problemas, creo. Y actualicemos esto. Ahí vamos. Y ahora NXC está, oh. Ya no están conectados porque alguien actualizó el código para romper esa línea. Bien, lo volveremos a poner. Y hagamos commit de esto como laboratorio cinco. Genial. Así que hemos terminado los laboratorios del uno al cinco. Comenzaremos con el laboratorio seis aquí. Y luego profundizaremos. Así que seis y siete completan la parte de código.

12. Creación de un CLI de Node y Compartir una Biblioteca

Short description:

En el laboratorio seis, agregamos un CLI de Node. Creamos una nueva aplicación de nodo llamada CLI NXG app CLI. En el laboratorio siete, compartimos una biblioteca entre el CLI y la API. Creamos una biblioteca de JavaScript llamada util interface e importamos en el archivo del repositorio de la API. Los objetos de juegos se les asigna el tipo de arreglo de juegos. El proceso de compilación se ejecuta sin errores.

Y luego, del ocho al trece, nos enfocamos más en el tipo de arquitectura y estructura del repositorio.

Vamos a ver, Andrix dice, Sí, Andrix, responderemos a tu pregunta en el laboratorio ocho. Así que llegaremos allí. Bien, empecemos con el laboratorio seis aquí. Y la respuesta es sí. Así que en el laboratorio seis, vamos a agregar un CLI de nodo. Básicamente, estamos creando otra aplicación de nodo. Mantenemos las instrucciones aquí al lado. Crea una nueva aplicación de nodo, llámala CLI NXG app CLI. No estoy especificando el complemento, así que debería preguntarme. Oh, sí, solo se ha generado una aplicación por ahora en nuestros complementos. ¿Qué framework quieres usar? Voy a decir ninguno porque solo quiero que sea un CLI. Y así se configura con el nombre CLI. Actualicemos el archivo main.ts con esto, copiándolo aquí. Ahora tenemos dos archivos main.ts, uno para el CLI. Actualicemos eso. Y esto no usa ninguna otra biblioteca, así que si ejecutamos nx-graph de nuevo, actualicemos esto, verás que el CLI no depende de nada más, solo tenemos una aplicación de nodo y luego el CLI en sí. Bien. Eso debería estar bien. Eso es el laboratorio seis. Genial.

Sigamos con el laboratorio. Oh, espera. Nos saltamos. Bien, ese enlace estaba equivocado. Queremos ir al laboratorio siete, no al laboratorio ocho. Bien. Laboratorio siete. Bien. Permíteme hacer commit de esto. Eso fue el laboratorio seis. Muy rápido el laboratorio seis. Si queremos... Permíteme mostrar rápidamente cómo ejecutar el archivo main.ts. Haríamos nxserve, lo ejecutaría. Así que si hago eso, nxserve-cli, oh, okay. Está intentando hacer una solicitud a localhost 333, pero la API no se está ejecutando. Así que si, acabo de ejecutar la API, y luego en una terminal separada ejecuto serve-cli. Bien, aquí vamos. Así que listó, hizo una llamada a la API y luego listó el nombre y la descripción aquí. Así que funcionó como queríamos. Parece que el final de barra no funciona en la consola 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í. Ahora queremos compartir una biblioteca entre dos aplicaciones diferentes. A veces, quieres tener algún tipo de conexión entre la aplicación de front-end y la aplicación de backend. Así que el CLI es nuestro front-end. Y cuando esa interfaz cambia, queremos que tanto el front-end como el backend se aseguren de que coincidan con esa interfaz. Así que vamos a crear un tipo de TypeScript para definir qué es un juego. Y tanto el CLI como la API utilizarán ese tipo de TypeScript. Y así se mantienen sincronizados. Así que cada vez que ese contrato cambie, estarán sincronizados. Eso es de lo que trata este laboratorio siete. Así que dejemos de ejecutarlo. Vamos a crear una nueva biblioteca de JavaScript, la llamaremos util interface. Y nos aseguraremos de colocarla debajo de la carpeta API. Luego, más tarde, la moveremos a otro lugar. Así que hagamos, nx generate library. La llamaremos API util interface. Aquí está mi atajo para asegurarme de colocarla debajo de la carpeta API aquí. Bien, y como no especificé el complemento, me preguntará cuál quiero. Quiero usar js, no node. Y realmente no me importa cuál de esos. Así que en apps tenemos eso, y ahora en libs tenemos libs api-auth y libs api-util interface. Bien, y ahora veamos qué sigue. Bien, cuando hago la interfaz del juego aquí, bien, mi enlace no es correcto. Source lib api-util interface y luego barra tal vez. No, okay. Tengo que buscarlo. Muestras lab7. Este es el correcto, api-util interface. Si alguien quiere puntos extra, puede corregir los enlaces rotos en mi código aquí. Bien, actualicemos eso. Y así exportamos el juego para api-util interface. Aquí. Bien, lo hicimos. 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 el archivo games.repository.ts, eso no es lo que quería. Esto, así que esto está en la API. Bien, y luego vamos a asignarle a estos objetos de juegos el tipo de arreglo de juegos. Bien, ahora estoy importando desde la biblioteca que acabo de crear y luego usando el tipo que se define allí. Bien, así que ese es el jugador. Luego lo compilaremos y nos aseguraremos de que no haya errores. Así que, NxBuild API. Bien, bien. Así que, nota aquí, cuando ejecuté NxBuild API, al principio estaba compilando la biblioteca util interface porque util interface también tiene una tarea de compilación definida.

13. Construcción y Movimiento de Bibliotecas

Short description:

El proceso de compilación para la API lleva más tiempo en comparación con la compilación de otras partes. Mover la biblioteca de utilidades de interfaz 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 utilidades de interfaz. El laboratorio 8 introduce el concepto de límites de módulos, que define reglas para las dependencias entre bibliotecas y aplicaciones.

Entonces, primero realiza la compilación para esto y luego realiza la compilación para la API en sí. NxBuild API es eso. Y luego, si lo ejecuto nuevamente, 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. Entonces, 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 la caché volverá en ¿qué, 49 milisegundos? Mientras que, ya sabes, el paso de compilación real podría llevar, ya sabes, dos minutos hasta 30 minutos, dependiendo de lo que estés haciendo.

De acuerdo, así que construimos eso y luego hagamos el... Vamos a verificar el gráfico del proyecto aquí. De acuerdo, aquí vamos. Refresquemos esto. De acuerdo, ahora tenemos esta nueva biblioteca creada y las API dependiendo de ella. Eso es bueno. ¿Ahora qué sigue? Vamos a confirmar todo, de acuerdo. Así que confirmaremos bajo el laboratorio, laboratorio siete. Hm-mm. De acuerdo, así que CLI hace llamadas a la API, pero está utilizando 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 se encuentra 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 utilidades de interfaz a un nivel superior para que esté directamente debajo de libs en lugar de debajo de la carpeta API. Entonces, 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í. Entonces dice, así que se está ejecutando eso, así que necesita un nombre de proyecto, hagámoslo 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 util interface, y quiero moverla en lugar de API/interfaz de utilidad. Veamos, de acuerdo, 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. Entonces, por lo general, no tienes que hacer mucho de este proceso de actualización porque no estás creando nuevos proyectos cada 30 segundos, pero en este taller lo estamos haciendo, así que. Entonces, API util interface, y luego queremos moverlo a util interface, y luego se está ejecutando esta simulación aquí, y así puedes ver los archivos que está creando. Entonces, está eliminando eso y moviéndolo, así que API/ 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 util interface cambia el nombre aquí, o podrías moverlo a una carpeta diferente aquí. Así que puedes hacer lo que quieras. Entonces, si te estresas por cómo nombrar la biblioteca o dónde poner las ediciones, no te preocupes, siempre puedes moverlo más tarde. Entonces, esto es lo que queremos, lo vamos a sacar de la carpeta API y moverlo a un nivel superior. Así que lo ejecutaremos, y ahora podemos ver los cambios que se hicieron. Um. De acuerdo, 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. Entonces vamos a tomar esto y luego supongo, problemas de formato aquí, pero está bien. Aquí. Y en el main.ts del CLI, veamos, entonces este val no es un NA, lo llamaremos game. Y necesitamos importar game aquí. De acuerdo. Ahora, si volvemos a nuestras instrucciones, veamos el games repository.ts. Si te fijas en el, esta ruta de importación se actualizó automáticamente para nosotros. Solía ser API/, y eso se actualizó cuando movimos nuestra interfaz de utilidad. Además, la ruta aquí se actualizó. Así que eso se encargó por nosotros, por el generador de movimiento. De acuerdo, ahora si ejecuto, de acuerdo, voy a arreglar esta alineación, porque esto es... Cambio, 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. De acuerdo. Bien, ¿qué estaba haciendo? Ejecutar el siguiente gráfico. Este. Así que ahora refresquemos esto. De acuerdo, ahora tenemos el CLI y la API. De acuerdo. Tengo que hacer un reinicio de NX aquí nuevamente. Por lo general, esto no hace esto. Entonces, 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 de utilidad y el CLI también depende de ella. Entonces, si esto cambia alguna vez, 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. De acuerdo. 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. Entonces, el laboratorio ocho, tenemos algunas diapositivas para eso. De acuerdo, digamos que tienes una configuración como esta, donde tienes múltiples frameworks que se utilizan en tu repositorio. Entonces 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 código de Remix solo puede usar código de Remix y código JS simple en la parte inferior aquí. El código de Angular usa código de Angular y esto, pero queremos tener alguna estructura en esto y tener reglas sobre qué bibliotecas pueden depender de otras bibliotecas. Entonces, eso es de lo que se encargan los límites de módulos para nosotros. Entonces, 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 API. Y luego tenemos cosas compartidas en la parte inferior. Entonces, las aplicaciones solo pueden cargar bibliotecas, las bibliotecas solo pueden cargar bibliotecas. Entonces, 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 diferentes partes de tu repositorio.

Entonces, cualquier sistema de etiquetado que tengamos, vamos a poder definirlo para nuestro repositorio, como agrupar cosas por tipo, nombre u otras 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. Por ejemplo, puedes decir que si una biblioteca tiene esta etiqueta de tipo 'util', que puede ser cualquier cadena que desees aquí, puedes decir que el tipo 'util' solo puede depender de bibliotecas que también tengan esa etiqueta de tipo 'util'. Y no pueden depender de nada con react, como cualquier dependencia de NPM, o cualquier cosa con el espacio de nombres Angular. Esa es la función de esta regla de Lint, 'enforce module boundaries'. Hay tres subcategorías diferentes dentro de esta regla de Lint, puedes decir que solo dependa de bibliotecas con una etiqueta específica, puedes hacer lo contrario, no puede depender de bibliotecas con cierta etiqueta. Y puedes tener reglas sobre importaciones externas, que son dependencias de NPM, cosas fuera del repositorio en las que no se les permite depender. Puedes tener una regla sobre prohibir dependencias transitivas, decir que 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 dentro de tu propia aplicación. Podría funcionar, podría compilar y funcionar correctamente. Pero luego, si express deja de usar esa dependencia, terminarás con una aplicación rota sin darte cuenta de lo que sucedió. Veamos. Entonces puedes decir que no hagas eso. Puedes verificar las importaciones externas anidadas. No estoy seguro exactamente de qué se trata eso. Entonces, por defecto, no te permite hacer una dependencia circular. Entonces, 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, está bien, permítelo por ahora hasta que encuentre cómo resolver ese problema. Eso es lo que son los límites de módulos. Permíteme 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, 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. Entonces, aquí, esta es la biblioteca del proyecto. Ahí es donde NX lo supo. Así que hagamos el siguiente laboratorio donde establecemos algunos de estos límites de módulos. Para configurar etiquetas, vamos a entrar en el archivo project.json para cada proyecto. Y vamos a configurar algunas etiquetas de alcance y algunas etiquetas de tipo. 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 acceso a datos, probablemente. Entonces, en esta etiqueta aquí, podemos hacer esto, 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 es la biblioteca de interfaz de utilidades. Así que esto es un alcance de shared y le daremos un tipo de util. Y luego tenemos otros dos proyectos para actualizar. Entonces, este es un alcance de CLI y un tipo de app. Esta es la aplicación API, así que le daremos un alcance de API. Tipo app. Podríamos hacer lo mismo para las aplicaciones de extremo a extremo, que en realidad no hemos usado en absoluto. No tiene etiquetas. OK. Si hay un proyecto aquí que en realidad no importa, entonces esta aplicación de extremo a extremo en realidad no importa ningún código de la aplicación API, pero queremos ejecutar las pruebas de extremo a extremo siempre que esta aplicación API cambie. Entonces puedes agregar manualmente una línea en el NXGraph definiendo estas dependencias implícitas aquí. Esto es simplemente decir manualmente que quiero una línea donde API ETE depende de API. Hay casos en los que necesitas hacer eso. Así que voy a agregar una propiedad de etiquetas aquí. Y te darás cuenta de que aquí tuvimos un autocompletado. Porque esto proviene de un NX console, leyendo el esquema para el archivo project JSON y sabiendo qué propiedades van aquí. Entonces, 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 nombrarlos como quieras, lo que tenga sentido para ti. Básicamente, basado en las reglas que quieras establecer. Así es como debes configurar tus etiquetas. Alcance CLI y tipo. Permíteme ejecutar el NX graph nuevamente. Y en el gráfico, en realidad muestra cuáles son las etiquetas. Entonces, si haces clic en estas cosas, muestra el alcance API, tipo ETE. Y esto es alcance shared, tipo UTIL. Así que esto puede ser útil. Ahora creo que nos hará hacer lo siguiente. Hemos configurado todas las etiquetas aquí. A continuación, vamos a definir nuestras restricciones de dependencia. Entonces, en el archivo root esland rc.json, vamos a agregar esto. Vamos a modificar esta regla y establecer algunas restricciones de dependencia. Voy a copiar esto. Y luego vamos a eslandrc.json. OK, esta es nuestra regla aquí, NX Enforced Module Boundaries y dependency constraints. Esta configuración predeterminada aquí dice que cualquier proyecto puede depender de cualquier otro proyecto. Así que queremos ser más restrictivos que eso. Así que vamos a eliminar eso y agregar nuestras propias reglas aquí. Si es el alcance de CLI, permíteme minimizar esto. Entonces, 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. Si es un tipo de app, en realidad debería poder depender de. Puede depender de cualquier cosa.

15. Linting y Prohibición de Importaciones en CLI

Short description:

Probamos el linting y nos aseguramos de que funcione. También demostramos cómo prohibir la importación de Express en la CLI. Los nombres de destino son arbitrarios, excepto para el destino 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.

Entonces podemos dejar eso sin especificar. Sí. Así que podemos hacer un tipo de acceso a data. Puede depender de tipo de acceso a data o tipo util. Y luego, el tipo util solo puede depender de tipo util. Muy bien, así que hagamos una verificación de cordura aquí y hagamos esto. Así que podría hacer un Nx Lint API para ejecutar el lint en un proyecto en particular, o podría hacer Nx run many con un destino de API, y esto por defecto ejecutará, no el destino API, sino el destino Lint. Y esto ejecutará el destino Lint en todo el repositorio. También puedes especificar una lista de destinos con una lista de proyectos con la bandera --project, pero queremos ejecutarlo en todo. Así que hagamos esto. OK, parece que todo sigue bien, así que veamos si podemos romper esta regla de lint y asegurémonos de que realmente funcione. Hagamos que una biblioteca util utilice una biblioteca de acceso a data. Así que vamos a ir a la interfaz util aquí, y aquí vamos a agregar una importación, queremos importar la función doauth. OK, lo importó, lo encontró, lo cual es bueno. Así que ahora ejecutemos la regla de lint en, en realidad, sí, no lo haría, en la nxLint util interface, tenemos un error. Dice que las bibliotecas construibles no pueden importar o exportar desde bibliotecas no construibles, OK, ese es un error diferente al que esperaba. Eso es un problema porque este tiene un destino de construcción, mientras que API-Auth no tiene un destino de construcción. Solo agregaremos algo aquí, pasará por alto eso. Así que agregamos un destino de construcción que no hace nada aquí, así que este es el error que esperaba. El proyecto etiquetado con alcance shared solo puede depender de los etiquetados con alcance secure. Bueno, eso no es exactamente el error que esperaba, pero también es válido porque Util Interface tiene alcance shared y API-Auth tiene alcance API. Por esa razón no debería permitirse. Esta regla también se violó, pero encontré esta primero. 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 cierta estructura a tu base de código. Sí, está bien. ¿Podrías prohibir express desde la CLI? Permíteme responder esa pregunta primero. Si lo hicieras, veamos. ¿Cómo lo hiciste? Sí. Así que haces esto. Etiqueta de origen alcance CLI. Podemos agregar otra propiedad aquí. Supongo que no autocompleta. Queremos agregar una prohibición de importaciones externas. Creo, ¿es eso? Permíteme buscar la documentación aquí. Nx.dev es el sitio de documentación. Quiero ir a paquetes y encontrar el linter. Linter aquí. Y luego, solo buscaré la imposición de límites de módulos. Claro. Buscaré la prohibición de importaciones externas. Así que esto está en paquetes. Oh, aquí está. Es el paquete eslintplugin.nx. Aquí están las opciones. Podemos agregar solo dependencias de vidas con etiquetas. Eso es lo que hemos estado usando principalmente. Pero también podemos hacer una prohibición de importaciones externas. Esta es una matriz de paquetes. Así que aquí, prohibición de importaciones externas. Eso es correcto. Y luego, es una matriz. Y luego, puedo poner express aquí. También puedes usar un comodín allí. Express star. Entonces, ahora, si voy a cli aquí y quiero importar desde Express. No le gusta. Dice, hey, no hagas eso. No permitido. Sí. Entonces Janik dice que los nombres de destino son arbitrarios. Son arbitrarios, excepto para el destino de construcción. Hay alguna lógica adicional alrededor de la construcción. Creo que eso es todo. Tenemos un término llamado biblioteca construible, que simplemente significa que tiene un destino de construcción. También hablamos de bibliotecas publicables, pero no creo que tengamos ninguna lógica especial al respecto. Simplemente se refiere a las bibliotecas que tienen un destino de publicación. Así que haré una abreviatura para eso. Había otra pregunta aquí. Janik preguntaba cómo recomendarías dividir una aplicación existente. Para una aplicación existente, ejecutarías. Entonces, solo para comenzar, ejecutarías index init para instalar index y configurar un archivo base index.JSON. Y luego, una vez que tengas una carpeta aquí que quieras convertir en una biblioteca, lo que harías es, si quisiera que este repositorio de juegos sea su propia biblioteca, haría básicamente index generate library y lo llamaría repository, tal vez games repository. Y luego supongo que sería JS, lo que quieras que sea. Y luego, básicamente tendrías que copiar este código en esa biblioteca recién creada. Así que lo copiarías y luego todas las referencias a eso tendrías que actualizarlas manualmente dentro de esta aplicación en sí. Hay un poco de proceso manual involucrado allí. OK. Agregamos eso. Creamos esto. Ejecutamos eso. Probamos eso. Probamos eso. OK. Probamos eso. OK. Asegurémonos de que nuestro linting esté funcionando. Nx run many. Otra cosa 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 linting, el linting ahora funciona correctamente. El comando Nx affected te permite ejecutar un objetivo específico en los proyectos que se vieron afectados por un cambio de código. Analiza el historial de git y se puede configurar con una rama base. Esto puede acelerar significativamente el tiempo de CI al omitir pruebas innecesarias. Tenemos tiempo para un tema más, y la audiencia votó por enfocarse en la configuración de CI y el almacenamiento en caché distribuido. Creamos un archivo de flujo de trabajo de CI que ejecuta npm install y pruebas para CLI y API. Confirmamos el archivo y lo enviamos a main. Eso es todo para el laboratorio 11, y ahora podemos pasar al siguiente tema.

Quiero mostrar el comando Nx affected. Muy bien. Primero, asegurémonos de que el linting esté funcionando. Nx run many. Objetivo igual a lint. Uno falló. Necesito arreglar esto. El VS code no ha captado nuestras nuevas reglas de linting. Si quieres solucionarlo, reinicias el servidor de linting de ES. Ahora tiene las subrayaciones correctas. Eso se debe a que cambiamos la regla y solo necesitaba actualizarse. Bien. Ahora, si arreglo eso, nuestro linting debería funcionar. ¿Notaste lo rápido que fue? Eso se debe a que la mayoría de estas cosas estaban en caché. Estos cinco objetivos de linting ya estaban en caché y solo necesitaba ejecutar este que acabo de cambiar. Si lo ejecuto de nuevo, es instantáneo de nuevo. Bien. Ahí está eso. Ahora, voy a confirmar esto y luego quiero mostrar el comando nx affected. ¿Cómo se llama este laboratorio 8? Así que digamos que si quisiera deshacer esto, en lugar de hacer nx run many para verificar y ver qué necesito ejecutar, puedo ejecutar nx affected. Entonces, este comando ejecuta un objetivo específico. Objetivo igual a lint. Esto significa ejecutar el comando de lint en cualquier proyecto que se haya visto afectado por un cambio de código en particular. Ahora mismo, he afectado este archivo. Analiza tu historial de git y puedes configurar una rama base si quieres. Puedes configurar la base y la cabeza. Pero por defecto, la cabeza 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 decirlo en Git, lo que está actualmente en tu sistema de archivos. Pero si ejecuto esto, se ejecutó. Veamos, nx run, nx affected. Se ejecutó. Así que se ejecutó. Así que se ejecutó para util interface, se ejecutó para API end to end y API end to end. Así que se ejecutó para cinco proyectos, lo cual tiene sentido porque este repositorio de juegos no se vio afectado. Veamos, ¿qué más no se vio afectado? API auth no se vio afectado. No hay razón para que el lint de API auth se vea afectado por este cambio de código. Pero estos otros, podrían modificarse potencialmente por el lint y podrían fallar porque he modificado algo de código aquí. Eso puede acelerar significativamente el tiempo promedio de CI porque no estás ejecutando pruebas que ni siquiera se ejecutan. Eso es el módulo de límites del laboratorio 8. Nos queda media hora. Veamos qué queda y seamos estratégicos acerca de lo que queremos hacer. Creo que tenemos tiempo para hacer, voy a dejar de compartir mi pantalla. Y para las personas que han llegado hasta aquí, tienen el poder de votar sobre de qué queremos hablar a continuación. Así que podemos trabajar en crear tus propios generadores que sean locales para tu repositorio, o podemos trabajar en la configuración de CI y el almacenamiento en caché distribuido. Vamos a usar la función de Levantar la mano de Zoom. Veamos dónde está la función de Levantar la mano. Pensé que sería una reacción, pero ahí está. Sí, en Reacciones. Así que puedes levantar la mano así. Levanta la mano si quieres hacer. Las opciones son generadores, generadores personalizados, o CI y almacenamiento en caché distribuido. Así que levanta la mano si quieres hacer generadores. Generadores personalizados. Tengo dos votos para generadores. Bien, tres votos para generadores. Puedes desactivar el silencio si estás tratando frenéticamente de encontrar el botón de Reacción. Muy bien, hagamos votos para CI y almacenamiento en caché distribuido. 1, 2, 3, 4, bien, parece que gana el almacenamiento en caché distribuido. Muy bien, así que si quieres ver los generadores, puedes hacerlo por tu cuenta. Eso es laboratorios 9 y 10. Pero voy a saltar al laboratorio 11. Así que aquí está el laboratorio 11. Configuramos CI. Bien, esto es configurar el almacenamiento en caché distribuido. Configurar CI. Espera, ¿lo hice bien? Sí, eso es correcto. Laboratorio 11. Espera. Bien, estamos en main. Necesitamos confirmarlo. Así que vamos a copiar esto y vamos a crear un archivo workflow.ci.yaml. ¿Cuáles eran todos estos? Debería estar en .github. Ahí. Nueva carpeta. Aquí. .github, y creo que es workflows. Y luego, un nuevo archivo. Ci.yaml. Pegarlo ahí. Bien. Esto hace que, cada vez que hay una PR, ejecutemos npm install. Hacemos checkout del último. Ejecutamos las pruebas para el CLI y ejecutamos las pruebas para la API. ¿De acuerdo? Hacemos eso. Y luego confirmamos eso en main y lo subimos. Muy bien. Déjame llegar a, ¿es este el 11? No recuerdo.

17. Pushing Changes and Updating CI

Short description:

Realizamos los cambios en el repositorio y creamos una solicitud de extracción. Las pruebas unitarias fallan, pero resulta que no hay pruebas. Actualizamos la configuración de CI para usar nx affected en lugar de objetivos específicos. Confirmamos 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 verifica en CI. Hacemos los ajustes necesarios y continuamos con el proceso.

Lo enviamos a. OK. Así que lo enviamos a mi. OK. Eso está funcionando. Eso está enviado. Agregamos un CI. OK. Así que vamos a abrir una nueva rama. Verificamos nuestro dash b. Modificado. Y luego nueva rama y actualizamos nuestro main.ts. Hacemos algún cambio. Hagamos, en realidad, el cli, main.ts, porque esto afectaría algo. OK. Ese es el nuevo mensaje que se mostrará en el cli, la terminal, y los cambios del autor y lo enviamos. OK, cambios realizados. Estos son mensajes de confirmación realmente buenos. Es como las Manos. Si has visto ese cómic de xkcd. Así que lo enviamos. OK. Y luego vamos a nuestro repositorio aquí, bg work. Primero, usamos la barra diagonal. OK. Vamos a hacer una solicitud de extracción aquí. Gran solicitud de empleado. Así que lo hemos hecho. 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 verificar eso en un momento. Estamos configurando eso. OK. 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 de xkcd. Voy a actualizar el CI.yaml. Así que en lugar de test-cli, solo estamos haciendo test-affected. Y en lugar de ejecutar npx nx-test-cli, vamos a hacer nx affected --target=test. Todo afectado. Y luego ya no necesitamos esto. Así que ese es el cambio que debemos hacer. Déjame ver si debo hacerlo en main o en nuestra rama. Vamos a hacerlo. OK, así que vamos a verificar esto dos veces. ¿Qué es eso, pasó. Interesante. Parece que nuestras pruebas unitarias no son muy buenas. Um, así que se ejecutó sí, la x, las pruebas siguientes cli, Oh, no se encontraron pruebas. Eso es por lo que ha pasado. Buen trabajo. Buen trabajo. Hemos tenido éxito en no ejecutar ninguna prueba. Ese es el mejor tipo de testing. Así que, um, ya sabes, nx affected no es útil. Si en realidad, uh, no tenemos pruebas, entonces, ya sabes, estás viviendo en el salvaje oeste en ese momento. OK, así que sigamos adelante. OK. OK. Así que hicimos ese trabajo. Um, testing, he estado ejecutándose secuencialmente para cada proyecto. Puedes ejecutarlos en paralelo. Por defecto, um, dash dash parallel está configurado en tres. Si quieres aumentarlo, puedes cambiar el número. O creo que puedes hacer parallel=1. Hacerlo en secuencia. Así que déjame, déjame confirmar esto y. OK. Así que estoy confirmando eso y luego veremos, um, veamos qué hace aquí en un momento. OK. Así que solo esas testing, así que también podemos, podemos hacer Lint ET y build. Así que podemos agregar más pasos aquí. Idealmente, querríamos hacer eso y luego hacer, uh, Lint y build. No estoy seguro si esto está en el último NX, pero pronto podrás hacer esto. Harán, um, en lugar de tener cuatro mentes diferentes. Pero, pero ahora mismo creo que tienes que hacer esto, todos los objetivos. Déjame verificar esto aquí. OK. OK. Así que este se ha actualizado y así que no se encuentra el objetivo de prueba o está fallando, los números están en main en revisión o la ruta no está en el árbol de trabajo. Oh, OK. Así que ese problema es porque no tenemos la rama principal verificada en CI, así que necesitamos, déjame ver aquí. Asegurémonos de que esto esté configurado correctamente. Eso es correcto. Eso es correcto. Vamos a verificarlo.

18. Configuración de CI y Caché Distribuida

Short description:

Este laboratorio se centra en configurar CI para usar NX affected y ejecutar solo las pruebas de código necesarias. Otro tema cubierto es la caché distribuida utilizando NX Cloud. El laboratorio muestra cómo especificar operaciones cachéables y proporciona un token de acceso para conectarse a NX Cloud. Los resultados de la ejecución, incluyendo los aciertos y fallos de caché, se pueden ver en NX Cloud.

Cualquier rama que esté utilizando la PR y CI probablemente no tenga la última rama hacia atrás. No quieres verificar cada rama. Creo que eso es lo que hace esto. Entonces en tu CI, probablemente quieras hacer algo diferente. Pero volvamos aquí. Y bien, ¿dónde está el? ¿Dónde estamos obteniendo las acciones? Obtener acciones de GitHub. Vamos a Por alguna razón, no aparecía en ese archivo de flujo de trabajo no válido, 913. Bien, no le gusta esto. Así que necesito otra sangría. Tal vez. Echemos un vistazo a ese. Bien, le gusta el archivo YAML. Eso es bueno. Todavía se llama test CLI, y eso es porque nunca cambié ese nombre. Pero solo hay uno de ellos, que es lo que esperamos. Y falló porque, bien, todavía no está verificando la rama principal aquí. La base necesita estar disponible para ello. Bien, tenemos que actualizar eso. Antes de ejecutar NXEffected, necesitas hacer esto. Bien. Así que encontré esto en la documentación aquí, buscando acciones de GitHub. Encontré esto al configurar eso, configurar eso, y luego hay este nodo aquí. Si estás utilizando la acción en el contexto de una rama, necesitas agregar esto, obtener rama rastrear main, origen main, antes de ejecutar NXEffected. Dado que la rama origen principal no existe. Permíteme asegurarme de que también estemos usando eso. Entonces esta acción aquí te ayudará a poder verificar qué puedes ejecutar afectado en función de la última implementación exitosa si estás haciendo CI. En nuestro caso, probablemente no lo necesitemos porque esto es solo para ejecutar pruebas y construir. Pero para una acción de implementación, querríamos hacerlo en función de la última implementación exitosa, no solo la última confirmación en la rama principal. Vamos a subir esto. Bien, entre nuestra privación y el usuario y solo el usuario, vamos a enviar 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 e implementar. Pero digamos que tenemos un Joker y queremos ponerlo en nuestra construcción, y luego devolver nuestra respuesta. Así que lo vamos a enviar. Bien, dejemos que eso falle. Bien, algo extraño está pasando aquí. Voy a abandonar y pasar al siguiente laboratorio. Así que básicamente, todo este laboratorio trata de configurar tu CI para usar NX affected. Y luego ejecutar, ejecutar solo el, solo solo testing el código que necesitas probar. Entonces, ese es un aspecto de la configuración de CI. Lo otro que quería mostrarte para asegurarnos de que no nos quedemos sin tiempo es en el próximo laboratorio. Laboratorio 12, caché distribuida. Entonces, puedes ejecutar esto o puedes ejecutar NX connect to NX cloud. Y, básicamente, está diciendo sí a lo que dijiste que no antes. Y lo que hará es agregar un, otro paquete aquí, este paquete NX cloud. Y agrega algunas configuraciones a tu archivo NX.json. Cambia el ejecutor del sistema de caché del ejecutor de tareas local a utilizar el sistema de caché distribuida de NX cloud. Entonces, y también, creo que estos son solo las operaciones de caché predeterminadas. Entonces puedes especificar qué cosas tienen sentido cachear aquí. Por lo general, la construcción es cachéable. Básicamente, es cualquier cosa que, solo cambia según las entradas. Cosas como servir no tienen sentido cachear aquí porque no hay una salida para cachear realmente. Cosas como cualquier cosa que haga una llamada de red. Entonces, a veces las pruebas ETE no deben cachearse si están haciendo una llamada de red a algún otro servidor que no controlas y la prueba de intención. Pero depende de cómo, según cómo hayas escrito tu prueba de intención, eso podría cachearse o no cachearse. No sé, hay algunas otras cosas que no tienen sentido cachear. Como una implementación, no quieres cachear tu paso de implementación. Entonces defines qué se debe cachear aquí y luego, al agregar NX cloud también te dio este token de acceso. Y lo que vamos a hacer es, cuando ejecutamos esto, nos envió este enlace aquí para reclamar nuestro espacio de trabajo en NX cloud. Y así, simplemente crearé un cloud. Continuaré con Google y usaré mi cuenta normal. Sí. Entonces, este es el token de acceso. Entonces, 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 vamos a conectarlo. Bien. Entonces, lo que esto hace es que cuando ejecuto, puedo ejecutar NX build CLI aquí. Se ejecutaron con éxito dos objetivos. Este mensaje no estaba aquí antes. Entonces, si hago clic en este enlace aquí, lo traigo de vuelta, puedo ver los resultados de esta ejecución. Entonces, 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, aunque 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 volveré a mirar aquí. Sigue abriéndolo en una ventana separada aquí. Todavía es 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, voy a hacer esto. Estricto en el almacenamiento en caché Decir un largo compromiso, seguro. Empújalo, súbelo. En realidad, déjame verificar la rama principal. Um, Bueno aquí, voy a fusionar esto y luego verificarlo.

19. Uso de la Caché Remota y NX Cloud

Short description:

Fusiona y confirma la fusión. Echa un vistazo al código en una carpeta diferente y demuestra el mecanismo de caché. Ejecuta NPM install y Nx build CLI. Descarga mi repositorio y ejecuta Nx build CLI. Configura un nuevo token. Haz commit y push de los cambios en el package lock. Ejecuta Nx build CLI nuevamente. Limpia la caché usando NX reset. Ejecuta Nx build CLI para obtener la caché remota. El informe muestra que se realizaron dos tareas 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 comprobar esto en una carpeta diferente, um, en una carpeta diferente. Copia eso. Y te voy a mostrar el mecanismo de caché. Clona esto y luego copia BG hoard. Voy a code, copia BG hoard. De acuerdo. Voy a ejecutar NPM install para configurarlo todo. Y cuál fue el comando que ejecuté, ¿ejecuté? Creo que fue build the CLI. Sí. Nx build CLI. De acuerdo. Así que ejecuté eso y ahora voy a ejecutar Nx build CLI aquí. Y esto es un repositorio completamente diferente aquí. Podría ejecutar esto en una máquina diferente, pero sería más difícil de configurar. 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ó correctamente la compilación objetivo y una tarea depende de la ejecución cero desde la caché. Veamos. Me pregunto si eso se debe a que tengo configurado un token de solo lectura. De acuerdo. Esto fue un fallo de caché y lo ejecutó todo de nuevo. Así que déjame ver. De acuerdo. Así que voy a generar un nuevo token aquí. Hay dos tipos diferentes de tokens, configuraciones de BG hoard, administrar tokens. Hay dos tipos diferentes de tokens. Ahora este es un token de lectura y escritura. ¿Por qué es eso diferente? Hmm. Me pregunto si, oh, hay un cambio aquí. ¿Qué es diferente? Mi package lock cambió. De acuerdo. Así que eso rompió, um, la compilación de Nx CLI aquí. Huh. De acuerdo. Voy a hacer commit de esto. Cambios en el package lock. Hago push de esto. Porque el package lock cambió, um, debería, correctamente, rompió la caché, correctamente dijo, necesito ejecutar esto de nuevo porque, um, si hay un package lock diferente, eso significa que tenemos una entrada diferente. Diferentes entradas en el sistema. Um, así que voy a ejecutar esto de nuevo. De acuerdo. Así que eso se ejecutó correctamente, lo leyó desde la caché. Permíteme volver al ahora. Ahora estamos en, estoy en el repositorio original aquí. Um, y voy a. Um, hacer checkout main. Oh, creo que ese es, ese es el problema. Um, estaba en una rama diferente y hay algunas otras cosas que eran diferentes, um, y si instalas, de acuerdo, entonces nada, nada es diferente aquí. De acuerdo. Um, de forma predeterminada, um, la caché se almacena dentro de node modules. Um, el punto cache es la carpeta NX aquí. Um, y esto tiene un hash para cada comando que he ejecutado y luego las salidas de ellos. Así que la salida del terminal y la. Ya 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 eliminará esa caché aquí. Mostrártelo, no lo hice. Um, NX, uh, hay un comando para borrar la caché. Déjame encontrarlo. Um. O puedo simplemente eliminar la carpeta, pero, um. No lo haría. Tal vez. Tal vez sea solo. De acuerdo. Eso fue solo mi sistema de archivos. VS code pensó que todavía estaba allí, pero no lo estaba. De acuerdo. Así que NX reset eliminó eso, eliminó esa carpeta. Um, así que eliminó esa carpeta. Así que ahora si ejecuto Nx build CLI, debería ir a buscar la remota que se creó, creada aquí. Sí. Y, y cargada. Así que el siguiente build CLI, um, ahí vamos. Así que este se cargó 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 se hicieron de forma remota. Así que si miro este, este comando, este, uh, informe aquí. Oh sí. Este informe. Así que este icono aquí dice que es una caché remota. No es local en mi computadora, se descargó de forma remota desde un experto en NX cloud. Entonces, um, y luego puedes, ya sabes, obtener la salida del terminal si quieres. No hay salida del terminal para ese, este tenía salida del terminal. Así que NX cloud es un producto de pago. Um, pero es, um, para repositorios más pequeños.

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

Short description:

NX Cloud ofrece caché distribuida y ejecución de tareas distribuidas. La caché distribuida ayuda en 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 Community Slack, cuentas de Twitter, videos de YouTube e interacciones en GitHub. Gracias por su atención y por ver hasta el final del video.

Hay una gran capa gratuita. Entonces, si tienes como 10 desarrolladores, probablemente nunca superarás la capa gratuita. Creo que obtuvimos 500 horas de tiempo de cómputo, de tiempo ahorrado por mes, de forma gratuita. Por lo general, una organización pequeña nunca llegará a eso. Y es gratuito para cualquier tamaño, si es un repositorio de código abierto. Para organizaciones más grandes, hay una versión de pago. Y también hay una versión enterprise. Si quieres. Si quieres alojar la caché en tus propios servidores, puedes habilitarlo de esa manera. Esto se configura para que, en toda tu organización, si alguien ejecuta una compilación en un conjunto de código en particular, puedes compartir ese trabajo con cualquier persona en toda la organización.

Muy bien. He estado hablando durante mucho tiempo y no he mirado las preguntas. Así que veamos si me he perdido algo. Bien. No veo preguntas. Así que nos quedan unos minutos. ¿Qué otras preguntas tenemos? ¿Hay alguna forma de hacer caché distribuida sin NX cloud? Teóricamente podrías crear la tuya propia, es decir, NX en sí es de código abierto. NX cloud no es de código abierto, pero si quisieras escribir tu propio mecanismo de caché distribuida. Esa parte no es demasiado difícil. La otra característica que olvidé mostrarte es, entonces, la caché distribuida es excelente para tu caso de uso promedio. Permíteme compartir mi pantalla nuevamente. Entonces, teóricamente, en una o dos semanas de tiempo de desarrollo, podrías escribir tu propia caché distribuida, solo tienes que encontrar la API en el código fuente y escribirlo tú mismo. Pero no sé por qué necesitarías hacerlo, francamente, porque los precios no son malos. Pero la otra característica que quería mostrarte que NX cloud también ofrece es la ejecución de tareas distribuidas aquí. Entonces, la caché distribuida ayuda en el caso promedio. Y si modificas algo que alguien ya ha hecho, simplemente usas sus resultados. Pero ¿qué pasa si modificas algo que está en la raíz de tu repositorio o algo que nadie ha calculado previamente para ti? Entonces necesitarás algo como la ejecución de tareas distribuidas. Y lo que hace es ayudar automáticamente a paralelizar todas tus tareas de la manera más eficiente posible porque NX conoce tu gráfico de dependencias. Por lo general, cualquier intento de paralelizar cosas en CI se ve así, donde tienes tres ejecutores diferentes, tienes algún tiempo inactivo y luego ejecutas pruebas y algún tiempo inactivo en tus compilaciones y luego algún tiempo inactivo después, y luego aterrizas y luego mucho tiempo inactivo, por lo que configurar manualmente qué tareas se ejecutan en qué servidores. Pero lo que hace DTE es que le dices cuántos agentes quieres y luego divide automáticamente las tareas entre esos agentes de la manera más eficiente posible porque sabe qué tareas deben ejecutarse antes de qué otras pruebas. Entonces dice: voy a ejecutar esas primero en este agente. Y tan pronto como eso esté listo, agregaré otras pruebas encima de eso. Por lo tanto, aprovecha al máximo la cantidad de agentes que tienes. Y si alguna vez necesitas escalar, simplemente cambias un tres por un diez y se escala instantáneamente a diez agentes. Mientras que si lo hicieras manualmente, sería mucho trabajo intentar configurarlo. Y esa es una característica más importante que incluso la caché distribuida. Porque eso te ayuda con tu peor escenario, algo que, sabes, tomaría dos horas, tomará media hora. Mientras que la caché distribuida básicamente tomará tu promedio de media hora y lo reducirá a un promedio de 15 minutos o algo así. Muy bien. ¿Otras preguntas? Puedes desactivar el silencio si quieres hablar verbalmente. O si estás distraído, está bien también. NX en sí es completamente gratuito. NX cloud es la única parte de pago. Sí, bueno. Si tienes, permíteme señalar, algunos de los recursos de la community. Entonces, si quieres chatear con otras personas que están trabajando en NX o que están intentando usar NX, si vas a NX.dev, este enlace a la derecha aquí es el Community Slack. Y puedes seguir a personas en Twitter. También publicamos muchos videos en YouTube, o simplemente interactúa en GitHub también. Esta área aquí tiene todas nuestras áreas de community, cosas de community. Sí, ha sido genial. Presentar contigo. Gracias por tu atención. Y saludos a todos los que vuelvan y vean esto más tarde. Buen trabajo por ver hasta el final del video. Muchas gracias. Sí, de nada. Fue genial. Muy bien. Gracias a todos. Adiós. Adiós adiós.

Watch more workshops on topic

React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
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

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.
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!
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!
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.