Monorepos de Node con Nx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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