React a Escala con Nx

Vamos a hablar sobre el desarrollo a scale con NxMonoRepos. Entonces, ¿qué es un MonoRepo? MonoRepo es un único repositorio que contiene múltiples proyectos distintos con relaciones bien definidas. Entonces, sabes, múltiples aplicaciones diferentes trabajando juntas, o podría ser una sola aplicación pero con múltiples subproyectos dentro de ella. Y luego necesitas tener relaciones bien definidas entre ellos. No puedes simplemente si solo tiras todo el code de dos aplicaciones diferentes en el mismo repositorio. Llamamos a esto colocación de code y es un desastre. Y te encontrarás con muchos problemas con eso. Y hablemos de cuáles son esas cosas.

Entonces, un monorepo es genial para permitirte tener cambios atómicos, te permite compartir code fácilmente y te permite tener un único conjunto de dependencias. Entonces, permíteme entrar en cada uno de estos y explicar qué son. Entonces, los cambios atómicos son, digamos que tienes una aplicación que consume una biblioteca de UI. Y si tienes esa biblioteca de UI en un repositorio separado de tu aplicación, entonces el flujo de trabajo de cambio es algo así. Digamos que haces un cambio en la biblioteca de UI que rompe una prueba en la aplicación. Entonces tienes que publicar esa biblioteca de UI, y luego en algún momento más tarde, el desarrollador de la aplicación aumenta su versión de la biblioteca y se da cuenta, hey, rompiste mi aplicación. Entonces te lo dicen, o presentan un problema al respecto. Y luego el desarrollador de la biblioteca tiene que volver y decir, está bien, voy a arreglar ese error y luego publicar una nueva versión de él que solucionará el error. Y luego, unos días después, el desarrollador de la aplicación aumenta su versión nuevamente y dice, está bien, eso lo solucionó. Entonces, todo ese ciclo de vida, eso es un mínimo de una semana probablemente, de tiempo real de desarrollador. Antes de que se haga el cambio hasta que se corrija y corrija. Mientras que si estuvieran en el mismo repositorio, entonces el desarrollador de la biblioteca simplemente ejecutaría las pruebas antes de hacer el commit. Simplemente ejecutarían la prueba y dirían, espera, rompí esa aplicación, la voy a arreglar. Entonces pasa de una semana de tiempo de ciclo a unos 30 minutos de tiempo de ciclo y no estás haciendo ese cambio de contacto, volviendo a esto en lo que trabajaste hace una semana para finalmente arreglarlo. Ese es un beneficio de un Monorepo. El segundo beneficio es compartir code. Entonces, si tienes alguna lógica de usuario para validar si un nombre de usuario es válido, y quieres reutilizar esa lógica en múltiples aplicaciones o múltiples subsecciones de tu aplicación. Si fueras a hacer eso en repositorios separados, tendrías que publicar eso y mantener los números de versión sincronizados. Mientras que en un monorepo, todo lo que necesitas hacer para compartir esa lógica es exportar una función y luego simplemente reutilizar esa función donde sea necesario. Por lo que es muy sencillo mantener esa lógica sincronizada. Si quisieras cambiar esta lógica de alguna manera, simplemente actualizas esa función y en todas partes se usa instantáneamente la nueva lógica actualizada. El otro beneficio es tener un único conjunto de dependencias. Entonces, digamos que tienes múltiples versiones diferentes de tu framework de Angular o react, eso puede causar errores extraños y raros. Si tienes una biblioteca que está en una versión antigua de react y la aplicación está en una versión más nueva de react, puede haber como, difícil de debug. Errores de tiempo de ejecución difíciles de debug que pueden ser causados por eso. El otro problema es que cuando tienes múltiples aplicaciones en diferentes, bueno, tienes múltiples aplicaciones, generalmente hay una aplicación, que es la principal en la que se trabaja todo el tiempo. Así que va a estar en la última versión de React. Versión del framework, pero luego si vas a tener otra aplicación que sabes que actualizas cada tres meses o algo así, tal vez cuando llegues a eso, y luego cuando vayas a actualizar eso, siempre es un dolor. Porque tienes que recordar, ¿cuáles fueron las cosas complicadas sobre la actualización a esa versión de React que fue hace seis meses, o hace un año. Y tienes que pasar por todos los mismos puntos de dolor que hiciste la primera vez, pero 12 meses después. Mientras que es mucho más fácil hacer todas las actualizaciones de la aplicación al mismo tiempo. Porque estás resolviendo el mismo problema en 10 lugares diferentes, en lugar de resolver el mismo problema en un lugar, por lo que no es tan difícil. Mientras que si lo haces 10 veces diferentes en el transcurso de un año, eso es realmente doloroso. Bueno, la colocación de code es donde simplemente juntas code sin tener una herramienta de monorepo en su lugar. Entonces, uno de los problemas que puedes tener es ejecutar pruebas innecesarias, no tener límites de code y tener herramientas inconsistentes. Entonces, pruebas innecesarias, digamos que cambias el proyecto de la página de inicio de productos, y eso depende de una biblioteca de UI. Entonces, si haces cambios en la página de inicio de productos, no hay forma de que hayas roto la prueba para la biblioteca de UI de productos. Entonces, no tiene sentido ejecutar esas pruebas, pero sin que tu tooling sepa acerca de cómo funciona este gráfico de dependencia, cómo funciona esa dependencia. No hay forma de que tu tooling pueda decir, estas pruebas necesitas ejecutar, estas pruebas no necesitas ejecutar. Entonces necesitas tener algo que conozca este gráfico de dependencia. Y entonces podrías teóricamente hacer eso tú mismo. Dices que sé que esta prueba necesita ejecutarse, estas otras pruebas no. Pero un repositorio normal que tiene múltiples aplicaciones, el gráfico del producto se ve más como esto. O incluso, he visto gráficos que tienen miles de nodos en él como este. Y entonces no hay forma de que puedas hacer eso en tu cabeza para asegurarte de que todas las pruebas se hagan correctamente cada vez. Entonces quieres tener una herramienta que pueda hacer esto por ti. Así te aseguras de ejecutar todas las pruebas que necesitas ejecutar, pero ninguna de las pruebas que están garantizadas de no haberse roto. La otra cosa son los límites de code. Digamos que tienes tu code en un repositorio compartido, y tienes alguna función con la que estás jugando. Está destinado para uso interno dentro de tu proyecto, y no quieres que otras personas lo usen, porque podría cambiar con frecuencia, ¿verdad? Pero alguien llega y comienza a usar esa función en su aplicación. Y luego en algún momento más tarde, la cambias. Has roto su aplicación, y están molestos contigo. Y entonces, ahora estás siempre en el gancho para mantener esa función con la misma API, o arreglar su code dondequiera que lo esté usando. Entonces, necesita haber alguna forma de decir, estas funciones están disponibles para que las uses. Estas funciones no están disponibles para que las uses. Para que puedas decir claramente, aquí está el límite, y esto es mi cosas, cosas internas. Esto es cosas públicas. Y la otra cosa es la inconsistencia en las tooling. Entonces, cada aplicación, cada proyecto tiene, pones en NPM script, tienes todo tipo de banderas y scripts extraños. Y entonces, cada vez que entras en una nueva base de code, tienes que averiguar, ¿qué significa esto? ¿Y por qué alguna vez ejecutaría esto? Y es realmente difícil saber eso en cada nueva aplicación. Entonces necesitas tener alguna forma de hacer esas cosas descubribles y bien documentadas. Así es como Nx puede ayudar.

Te brinda todos los beneficios del monorepo sin las desventajas de la colocación de código. Por lo tanto, puede brindarte una ejecución de comandos más rápida, compartir código de manera controlada, prácticas de codificación consistentes y un diagrama de arquitectura preciso. Así que una ejecución de comandos más rápida. Hay ejecutores, que te ayudan a ejecutar las tareas que necesitas ejecutar en tu código, la construcción, las pruebas y esas cosas. Nx Affected te permite ejecutar comandos solo en proyectos que se vieron afectados por un cambio de código y no en nada que no se vio afectado. Y el almacenamiento en caché local y distribuido también acelera tu tiempo de ejecución promedio en CI o localmente al decir si las entradas para esta tarea no han cambiado, entonces sé que la salida ya es la que se hizo antes. Y simplemente lo obtiene de la caché en lugar de volver a ejecutarlo. Y el almacenamiento en caché distribuido te permite compartir esa caché en toda tu organización en lugar de solo localmente en tu máquina. Compartir código de manera controlada, puedes configurar una API para tus proyectos y decir que estas son las funciones que son públicas para que las use cualquier persona y estas son las que no se exportan en el archivo de API, ese archivo indexado TS es privado, por lo que no se puede usar. Puedes configurar etiquetas para decir que estos tipos particulares de proyectos pueden depender de estos otros tipos de proyectos, pero otros no pueden. Y así, cualquier estructura que necesites hacer para tu propia organización, puedes decir que estos tipos de proyectos se pueden usar dentro de este equipo y estos otros proyectos se comparten para que cualquiera los use. Entonces, cualquier tipo de estructura que necesites hacer con esas etiquetas, puedes hacerlo. También puedes crear bibliotecas publicables para publicar en NPM. Utilizas un archivo de propietarios de código, que es una función de Git que dice que si haces cambios dentro de estas carpetas, estas personas en particular deben aprobar la PR antes de que se pueda fusionar. Así que todas esas cosas son útiles para administrar un repositorio grande. Prácticas de codificación consistentes, por lo tanto, Nx proporciona reglas de linting, los generadores te permiten generar y modificar código. Así que mantener las cosas actualizadas y agregar nuevo código de manera consistente. Hay complementos proporcionados por Nx que son oficiales, y también hay complementos de la comunidad. Cualquiera puede escribir un complemento y publicarlo y decir, esto te dará soporte para alguna herramienta que Nx no haya admitido oficialmente. Y luego puedes tener un diagrama de arquitectura preciso. Entonces, Nx comprende cómo se relacionan los diferentes proyectos entre sí. No solo la forma en que crees que dependen entre sí o la forma en que deseas que dependan entre sí o la forma en que dependían entre sí hace seis meses. Es lo que el código dice acerca de cómo estos proyectos dependen entre sí, lo cual es invaluable para realmente tener una vista precisa de qué pruebas realmente deben ejecutarse y cómo los proyectos deben, qué tareas deben ejecutarse antes de qué otras tareas, ese tipo de cosas.

De acuerdo, esta es una estructura de carpetas típica para Nx. Nx, hay diferentes estilos de un repositorio Nx. Vamos a utilizar el estilo integrado en esta masterclass, que es el diseño que estás viendo aquí. La configuración de repositorio basada en paquetes puede ser básicamente cualquier estructura de carpetas que desees, y básicamente lo que obtienes con el repositorio basado en paquetes es que tienes menos soporte para los complementos, como los ejecutores y la co-generación. Algunas de esas cosas pueden funcionar o no tan bien, pero con el estilo integrado obtienes todas las funcionalidades principales de Nx y los complementos y generadores funcionan como esperas.

Entonces, hay un directorio de aplicaciones, que tiene todas tus aplicaciones, y luego un directorio de bibliotecas, que tiene bibliotecas. Las aplicaciones consumirán código de biblioteca, y la diferencia entre una aplicación y una biblioteca es que una aplicación tiene una forma de implementarla básicamente o una forma de, tiene una característica publicada, es como un punto de entrada para tu código. Y donde las bibliotecas son cosas que serán consumidas por otras bibliotecas o por aplicaciones. dist es donde se genera el código de construcción, herramientas para scripts u otras cosas de ayuda. Ya no usamos workspace.json. Index.json es tu código global, archivo de configuración global para index en sí. Y veamos, tsconfig.base.json tiene alias de rutas de TypeScript para que puedas hacer referencia a bibliotecas con un alias conveniente. Luego tenemos la configuración a nivel de espacio de trabajo y la configuración a nivel de proyecto. Entonces, si tienes configuraciones de TypeScript en tu tsconfig.base.json y necesitas sobrescribir eso para un proyecto en particular, puedes hacerlo a nivel de proyecto. Entonces tsconfig.json hereda de la configuración base, pero luego puedes sobrescribirla para cambiarla según las necesidades específicas que tengas para ese proyecto. Y lo mismo para Jest y otras herramientas.

De acuerdo, esto es lo que vamos a hacer. Este es el cronograma. Excepto por reemplazar Angular por React en él. El primer laboratorio, vamos a crear un nuevo espacio de trabajo. Entonces vamos a utilizar, déjame, sí, está bien. Cuando creas un nuevo espacio de trabajo, ejecutas npx create-nx-workspace o yarn create-nx-workspace. Y le das un nombre y ese nombre se utiliza para tres cosas diferentes. Se utiliza para el directorio en el que se coloca, se utiliza para el alias de ruta. Entonces, cómo importas una biblioteca es que si estableces my-org y la usas simplemente como el nombre, estará en my-org/ el nombre de la biblioteca. Y luego se utiliza para el ámbito de NPM. Si las cosas se publicaron, si alguna vez publicas una biblioteca desde tu repositorio, tendrá ese ámbito. Ahora todas estas cosas se pueden modificar más adelante, pero por defecto, todas se establecen en lo mismo cuando creas un espacio de trabajo. De acuerdo, así que vamos al primer laboratorio aquí. Esta es la aplicación que vamos a hacer. Vamos a bajar aquí y vamos al laboratorio uno. De acuerdo, así que vamos a crear un nuevo espacio de trabajo y llamarlo BG Horde, y va a ser integrado y un diseño de aplicaciones. Así que hagámoslo. Permíteme verificar rápidamente si hay preguntas. De acuerdo, bien. Así que si tienes preguntas mientras avanzamos, ponlas en Discord. De acuerdo, así que hagamos yarn create-nx-workspace y le daremos el nombre BorgGame Horde. En realidad, necesito eliminar el BorgGame Horde que ya está ahí. De acuerdo, yarn create-nx-workspace B, G, Horde, y déjame hacer esto, asegurémonos de tener lo último. Oh, eso es una cosa de NPX, está bien. Sí, está bien, eso es correcto. De acuerdo, así que hagamos 16.1.4. Así que si estás siguiendo, utiliza 16.1.4 en lugar de 16.2.0. Creo que eso se publicó hoy. Entonces, integrado y aplicaciones. Y haremos no a la caché distribuida, ya lo agregaremos más tarde. Um, okay. No creo que 16.2.0 deba ser publicado, voy a intentar NPX, create-nx-workspace, vg-horde. ¿Qué versión está haciendo eso? De acuerdo. Esto es lo que tengo que hacer para obtener la última versión. De acuerdo. De acuerdo, así que hagamos 16.1.4. Entonces, si estás siguiendo, haz 16.1.4 en lugar de 16.2.0. Creo que eso se publicó hoy. Entonces, integrado y aplicaciones. Y haremos no a la caché distribuida. Así que creo que solo se creó create-nx-workspace para 16.2.0 y el resto de NX no se publicó para 16.2.0, porque todavía está en beta. Entonces no estoy seguro de por qué se creó create-nx-workspace. Así que si especificas específicamente 16.1.4, no estoy seguro de cómo especificar exactamente una versión en yarn create. ¿Alguien sabe cómo hacer eso, hacer algo como un guión guión versión? Aquí está, guión V. No, eso solo lo muestra. Intenta poner un número de versión después de tu cosa. Sí, lo intenté y se confundió. Con archivo o directorio de mensaje binario. Por cierto, funciona para mí, así que vamos a ir aquí. Y este es nuestro nuevo repositorio. Entonces, si quiero usar yarn en su lugar, puedo eliminar el registro de paquetes y hacerlo. Ahí vamos. Así que avísame si tienes problemas, o si estás siguiendo. Deberías tener NX 16.1.4 aquí y NX Workspace con la misma versión. Es importante que estos números se mantengan sincronizados entre sí. De lo contrario, buscarán funciones o valores que no existen.

Vale, no tenemos aplicaciones ni bibliotecas, solo algunas cosas básicas aquí. Muy bien, sigamos adelante.

Muy bien, laboratorio dos, hablamos de los complementos. Si ejecutas NX list, mostrará todos los complementos que tienes instalados y también mostrará otros complementos que puedes agregar. Para agregar un complemento, simplemente lo instalas con npm o yarn y luego puedes usarlo. Los complementos tienen generadores y ejecutores, y algunas otras cosas que interactúan con el NX Graph, ampliando el NX Graph. Pero la mayoría de ellos hacen generadores y ejecutores. Los generadores actualizan tu código o lo modifican de alguna manera, mientras que los ejecutores ejecutan tareas en tu código de alguna manera. Puedes ejecutar generadores desde la línea de comandos con nx generate, o puedes usar el complemento NX console editor. NX console está disponible para VS Code y para los productos IntelliJ Webstorm y otros. Eso te dará una interfaz de usuario que muestra todas las banderas disponibles para un generador específico y te permite ejecutar cosas de esa manera. NX proporciona complementos oficiales que te brindan soporte para diferentes frameworks como Angular, React y Storybook, y herramientas de prueba como Jest, Protractor y Cypress, y también herramientas de linting como Prettier y ESLint, y otras herramientas de backend. También puedes crear tus propios generadores locales, crear tu propio complemento local que solo se utiliza dentro del repositorio. Eso te permite crear básicamente una forma automatizada de repetir tareas que haces regularmente. Cada vez que creas una nueva página, generalmente es un proceso de ocho pasos que está en algún lugar de un archivo readme. Y las personas siempre olvidan los pasos tres y siete. Entonces, si escribes un generador para eso, puedes asegurarte de que se haga de manera consistente. Y todo lo que tienen que hacer es escribir el nombre de la nueva página y se completa automáticamente. Esa es una excelente manera de aumentar la consistencia en tu código base. Muy bien, hagamos el laboratorio dos. Voy a crear una aplicación React aquí. Permíteme consultar las instrucciones. Laboratorio dos. Vamos a crear una aplicación React. Entonces, hagamos Nx version, asegurémonos de tener Nx --version aquí. Tenemos 16.1.4, que es lo que esperamos. Y hagamos Nx list para ver lo que tenemos. Los complementos instalados solo son Nx, que es lo que esperamos. Y tenemos todos estos complementos oficiales disponibles para agregar. También hay complementos de la comunidad. Podemos ir a este enlace para verlos. Así que tienes todos estos, estos son los oficiales. Y si te desplazas hacia abajo aquí, puedes ver que hay muchos complementos de la comunidad. Así que si busco aquí, buscaré en la parte superior. Busquemos uno de Java. Java. Vale. Tal vez se llame Spring. Ahí está. Hay uno de Spring, que es Java. De todos modos, puedes buscar otros complementos allí. Muy bien, vamos a agregar NX React. Y también agregaremos algunos otros paquetes que necesitaremos más adelante. NX React y Material UI para agregar algo de estilo. Vale, agreguemos eso. Y también 16.1.4, que es lo que esperamos. Esto debería ser una dependencia de desarrollo, pero no importa mucho. Muy bien, ahora necesitamos usar este complemento React para generar una aplicación de almacenamiento. Así que esto es lo que vamos a hacer. Podría hacer nx generate nx react application de esa manera, y luego me preguntará qué nombre quiero, pero voy a usar la consola NX aquí y voy a decir que quiero generar, y encontró la biblioteca React, un complemento React, y me muestra todos los generadores disponibles, así que voy a hacer application aquí y ponerle el nombre de Store. Está bien, y puedo elegir un empaquetador, vamos a usar webpack, porque es lo que se utiliza en la masterclass, pero tú puedes usar VEET o RSPack por tu cuenta, y luego puedes especificar un directorio donde quieres ponerlo si quieres. Hay más opciones si haces clic en mostrar más, hay muchas cosas que se pueden agregar aquí, pero lo dejaremos así y lo ejecutaremos. Ahí vamos. La primera vez que creas una aplicación, tiene que instalar todas las cosas necesarias, así que va a agregar, espera a que termine, pero eventualmente actualizará tu package.json con el framework React que necesitas, y sí, aquí vamos. Todas las bibliotecas necesarias para React, ESLint, Jest, que vienen por defecto, y algunas otras cosas. Y aquí, NX console sabe que ahora tengo la aplicación Store y una aplicación de extremo a extremo de Store. Puedes verlas debajo de apps aquí. Así que tenemos Store y Store end-to-end. Muy bien, dejemos que se ejecute y haremos el siguiente paso aquí. Vamos a crear un archivo API.ts falso. Y vamos a hacer una nueva aplicación C2 copy, copy. Fake API, quiero ponerla en cualquier lugar de la carpeta de almacenamiento. Y aquí, voy a crear un nuevo archivo, fake API.ts. Pegarlo aquí. Así está bien. Muy bien, hemos terminado eso.

Paso siete, vamos a actualizar el TypeScript y el CSS. Así que, app.tsx se modifica de esta manera. Nuestro app.tsx predeterminado está utilizando, algún código de bienvenida introductorio aquí que te dice, hey, esto fue hecho por NX y te da algunos pasos siguientes, te señala algunos tutoriales. Y luego tenemos los módulos SCSS de la aplicación. Que en realidad necesitamos renombrar aquí. Esto está apuntando a SCSS, no a CSS. Aunque en realidad no importaría si esto fuera CSS.

De acuerdo. Ya tenemos eso. Bien. Luego podemos copiar las imágenes de ejemplo. En realidad, las voy a copiar desde una carpeta diferente, pero tú puedes descargarlas. Mira, está... Mira, está completo. Voy a soltar las imágenes aquí. Así que si estás haciendo esto tú mismo, descargas cada una de estas tres y las pegas aquí. Pero yo ya las tengo localmente. Así que las arrastro aquí. Bien, ahora vamos a servir esta tienda y ver cómo se ve. NxServeStore, así que podemos hacer esto con la CLI de esta manera, o también podemos usar la NxConsole aquí. Expandimos esto, puedes hacer clic en servir, ejecutarlo así, o puedes hacer clic en servir aquí y elegir la aplicación que deseas. Sí, hacemos clic en eso y lo ejecutamos. Está disponible en localhost 4200, y aquí vamos. Tenemos algo de estilo, tarjetas de material y se muestran algunas imágenes. Genial. Así que eso es bastante bueno. Sin mucho esfuerzo, tenemos una configuración básica con React, y tenemos pruebas y linting ya configurados para nosotros. Si ejecutamos las pruebas, fallarán porque hemos cambiado el código, pero la infraestructura está ahí para nosotros. Y podemos hacer NX Lint, store, eso funcionará. Y tenemos pruebas N2N. Puedes ejecutar NXETE store ETE. Y eso lanzará la aplicación y ejecutará pruebas Cypress en ella, que también fallarán porque he cambiado el código de la aplicación. Pero si la infraestructura está en su lugar para que modifiques esas cosas.

De acuerdo. Sigamos con las siguientes diapositivas. Permíteme revisar Discord nuevamente. Siguiente. Sí. Entonces, en, en sí, debes especificar cuando creas el siguiente espacio de trabajo, debes especificar la versión 16.1.4. Sí. Mayo lo especificó. Sí. El problema es que la versión 16.2 está buscando la versión NX 16.2, que aún no se ha publicado. Así que la Creación de Espacio de Trabajo NX 16.2 no debería haberse publicado, pero lo hizo. Así que eso es, eso es por qué. Así que si sigues a Males, copias el comando de Males, debería funcionar. De acuerdo, volvamos a Keynote aquí. De acuerdo. Acabamos de hacer el laboratorio dos. Ahora hablemos de los ejecutores. Usamos el generador para crear la aplicación, y hablaré sobre los ejecutores. Los ejecutores se definen en tus archivos Project.JSON. Y si tienes algo definido en los scripts de npm utilizando la configuración basada en paquetes, no tienes ejecutores. Pero aún puedes ejecutar tus scripts de npm utilizando NX. Solo estamos comprando, ya sabes, NX. Si tienes un script de construcción en tu script de npm, haces nx build, el nombre de tu proyecto. Pero los ejecutores te brindan una... Los ejecutas utilizando, ya sabes, esta línea de comandos. También puedes ejecutarlos con NX Console. Lo mismo ocurre con los scripts de npm. Pero lo que te brindan los ejecutores es que las banderas son descubribles. Con los scripts de npm, no tendrías estos campos aquí en NX Console. Tampoco tendrías, serían descubribles en términos de cuál es su nombre y podrías ejecutarlos, pero no podrías decir, déjame agregar esta otra bandera y tener esta línea aquí que te diga qué hace cada bandera. Eso es lo que te brindan los ejecutores. Así que pasemos al siguiente laboratorio, y vamos a explorar lo que hacen por ti.

De acuerdo, vamos a construir la aplicación. Acabamos de hacer un servir aquí, permíteme hacer un commit de esto, esto es lo que hicimos en el laboratorio dos. Veamos el proyecto, bueno, lo construiremos, NX build the store. No, no store, eStore. De acuerdo, lo construimos, y si miramos en la carpeta de disco, tenemos la salida de construcción aquí. Entonces, ¿qué pasa si queremos... todo funcionará, si miramos en el main.js, tienes esto y todo ese galimatías. Así que miremos en el archivo project.json. Entonces, si miramos bajo construcción, está utilizando el ejecutor de webpack, y tenemos la ruta de salida, tenemos base href, un montón de cosas aquí, algunos activos que se están copiando. Así es como vemos que las imágenes que se crean, así es como defines de dónde vienen. Así que está copiando toda esta carpeta. De acuerdo, queremos enviar una bandera al ejecutor para que construya para producción. Hagamos esto. Hay dos configuraciones diferentes aquí. Estas configuraciones, comienzan con estas opciones aquí arriba y luego las sobrescriben de una manera específica. El desarrollo tiene estas cosas configuradas como falso, estas como verdadero y la producción tiene algunas sustituciones de archivos que están ocurriendo y luego algunas otras opciones que sobrescriben estas opciones. Así que si, veamos, si ejecuto esto, la opción de configuración predeterminada es producción. Así que si, si haces NxBuild-store "-configuration="production", es lo mismo que lo que ya hicimos. Pero también podrías hacer desarrollo. Y eso tiene algunas configuraciones diferentes aquí. Así que si miramos, ahora tu main.js no tiene la minificación que ocurría con la construcción de producción. Sí. Así que tenemos esto, mira un poco más abajo. El objetivo de servir, podemos mirar aquí y podemos ver que colapsamos esta construcción. El objetivo de servir utiliza el objetivo de construcción. Así que servir dice, utiliza todas las mismas opciones que están en la construcción, pero solo sírvelo en lugar de construirlo. De esa manera, solo tienes un lugar para cambiar estas opciones aquí. Así que cuando estás en modo de desarrollo, cuando estás en modo de desarrollo, siempre usas esto, ya sea que estés construyendo o sirviendo. Sí, genial. Así que esa es una breve introducción a los ejecutores. De acuerdo, eso es otra revisión rápida de Discord. Lo siento. Sí. Tengo una pregunta sobre la tarea como servir, un enlace, algo así. Es completamente configurable. ¿Elegimos lo que queramos? Sí, las tareas. Sí, aquí, así que estos nombres son totalmente arbitrarios.

Puedes poner lo que quieras ahí. Estos ejecutores deben ser un ejecutor específico que esté disponible. Entonces, esta parte es el nombre del complemento. Y luego este es el nombre del ejecutor. Y luego cada ejecutor tiene sus propias opciones que están disponibles aquí. Así que si tienes NxConsole, debería tener autocompletado. Ahí vamos, sí. Entonces, si tienes habilitado NxConsole, autocompletará las opciones que están disponibles aquí leyendo los metadatos proporcionados por este ejecutor. Estas opciones cambiarán según el ejecutor que sea. Y luego estas configuraciones, las opciones que están disponibles aquí, son las mismas que están disponibles en las opciones de arriba.

¿Eso responde a tu pregunta? Sí, gracias. Sí. Y luego hay algunas otras opciones aquí que no son específicas del ejecutor. Entonces, las salidas, esto entra en juego cuando se hace almacenamiento en caché. Y luego también se pueden especificar entradas. Creo que llegaremos a esto un poco más tarde. Y luego la configuración predeterminada, esto es cuando no especificas una configuración, qué se va a utilizar. Si quieres que esto sea desarrollo, puedes hacerlo. O si, lo mismo con los objetivos. Los nombres de configuración son totalmente arbitrarios. Puedes llamarlo puesta en escena o lo que quieras hacer. Ahí. Algunas personas están escribiendo. Sigamos adelante. Eso fue el laboratorio tres. Así que tendremos otra media hora antes de nuestro descanso.

Entonces, las bibliotecas, diferentes tipos de bibliotecas. Así que simplemente generamos una aplicación sin ninguna biblioteca. Entonces, las bibliotecas, puedes nombrar las bibliotecas como quieras. Pero encontramos que típicamente hay cuatro tipos diferentes de bibliotecas que la gente tiene, una biblioteca de características, que es como una página o algo así como una característica de nivel superior. Una biblioteca de interfaz de usuario, que serían componentes de presentación que se pueden reutilizar en muchos lugares diferentes. Bibliotecas de acceso a datos, que manejan cosas como obtener datos de una base de datos o hacer llamadas a la red, almacenar y almacenamiento local, ese tipo de cosas. Y luego, las bibliotecas de utilidades, que son funciones y constantes puras de JavaScript. cosas así.

Y típicamente, tienes bibliotecas de características que pueden usar cualquiera de las otras bibliotecas. Las bibliotecas de interfaz de usuario solo pueden importar otras bibliotecas de interfaz de usuario o bibliotecas de utilidades. Y las bibliotecas de acceso a datos solo pueden usar otras bibliotecas de acceso a datos o bibliotecas de utilidades. Y luego, las bibliotecas de utilidades solo pueden importar otras bibliotecas de utilidades. Así que tienes esta estructura establecida para cómo configuras las cosas. Las bibliotecas también se pueden anidar en carpetas. Entonces, típicamente, si tienes una aplicación de almacenamiento, tendrías todas las bibliotecas que están destinadas a ser solo para esa aplicación dentro de una carpeta de almacenamiento dentro de libs. Y luego, las bibliotecas que están destinadas a ser compartidas en todo el repositorio debajo de una carpeta compartida. Pero puedes mover las bibliotecas fácilmente. Así que no tienes que preocuparte demasiado por dónde las colocas inicialmente. Tenemos un generador para mover las cosas. Y puedes tener tu propia estructura, por supuesto.

La gente a menudo nos pregunta cuándo deberían dividir el código en una nueva biblioteca. Y ¿cuándo tengo demasiadas bibliotecas? Como cualquier cosa, esto es un compromiso. Cada operación que realiza NX es a nivel de biblioteca o proyecto. Entonces, cuanto más dividas el código en múltiples proyectos, más podrás aprovechar el almacenamiento en caché de NX o la generación de código de NX, cosas así, y el comando efectivo, ese tipo de cosas. Entonces, si tuvieras todo dentro de un solo proyecto de aplicación, entonces no hay mucho sentido en usar NX. No hay mucho uso en eso. Pero por otro lado, si pones cada componente en su propia biblioteca, eso probablemente sea demasiado, porque eso tiene un costo. Estás generando más carpetas y luego, cada vez que haces cambios en el código, tienes que buscar en muchas carpetas diferentes para entender qué está pasando. Entonces, al igual que cualquier otra cosa, quieres mantener juntos el código que tiene sentido juntos, pero cuando comienza a crecer, es cuando divides las cosas en múltiples bibliotecas. Así que puedes visualizar el gráfico de tu proyecto para ver cuál es la estructura de tu repositorio. Este es el propio repositorio de NX. Aquí hay un video. Curioso con esta decisión. De acuerdo, puedes agrupar cosas, puedes filtrar las cosas y asegurarte de que solo se muestren partes específicas del gráfico. Entonces, con cualquier repositorio de tamaño razonable, obtendrás cientos de nodos. Y en ese punto, una representación estática del gráfico es completamente inútil. Entonces, necesitas tener algún tipo de filtrado como este para poder usar el gráfico tú mismo y obtener algún valor de él. Así que, eso.

Y luego creo, bueno, así que pasamos al laboratorio cuatro. En realidad, una pequeña desviación aquí. En realidad, una pequeña desviación aquí, laboratorio 3.1, migraciones. Entonces, migraciones. Los NxGenerators no solo se utilizan para generar nuevo código. También puedes usarlos para mantener el código de las personas sincronizado. Como autor de una biblioteca, puedes usarlos para mantener el código de las personas sincronizado. Cada vez que realices un cambio que rompa la compatibilidad, puedes lanzar una migración que mantendrá a las personas actualizadas con la última versión de tu biblioteca. NX hace esto para todos nuestros complementos proporcionados. Entonces, puedes ejecutar NxMigrate, y eso actualizará todo tu código a la última versión de Nx. Luego puedes ejecutar los scripts de migración en sí. Luego, cualquier cambio que rompa la compatibilidad que haya sido realizado por nuestros complementos se migrará automáticamente por ti. Entonces, facilita mucho mantenerse actualizado a la última versión de las cosas. Entonces, estamos usando la misma herramienta para saltar a diferentes partes de la masterclass. Diferentes laboratorios en la masterclass. Entonces, si alguna vez te quedas atrás, puedes instalar este paquete NARAL nxreact-workshop, y luego puedes ejecutar las migraciones aquí. Así que voy a demostrar eso rápidamente. Así que voy a hacer yarn add-d al taller. Y luego voy a ejecutar. Bueno, esto sugiere que agreguemos el más antiguo, pero acabo de agregar el último. Entonces, si esto fuera, si esto fuera, si agregara uno antiguo, podría ejecutar xmigrate, simplemente ejecutaría xmigrate. Eso hará todo en tu package JSON. xmigrate. Puedes hacer xmigrate latest. Eso hará todo. Oh, no. Bueno, está bien. Bueno, supongo que verás qué hace esto. Entonces, si haces un xmigrate latest, hace todo. Entonces, aparentemente, durante nuestro taller en la última hora, publicaron 16.2.1, que probablemente sea por qué CreateNX workspace estaba haciendo cosas extrañas. Y así podrás ver qué sucede cuando actualizamos. Entonces, creó algunos scripts de migración en este archivo migration.json. Elimina la ruta de salida para los comandos de ejecución. Normaliza, hace algunas cosas con Cypress, y arregla el renderizador de pruebas de React. De acuerdo, esas cosas, seguro.

Vamos a ejecutar esos. Entonces, para ejecutarlos, asegurémonos de tener instaladas las últimas versiones de los paquetes. Luego, ejecutaremos nxmigrate run migrations. Y nxmigrate con el indicador --run migrations aquí. Lo que hace es buscar dentro del archivo migrations.json y ejecutar cada uno de estos generadores. Voy a ejecutar eso. Y probablemente no cambie nada, pero tal vez sí. Cada vez que ejecutas un, veamos. Parece que no se cambió nada. Veamos. Sí, parece que no se cambió nada. Pero revisó mi código para ver si se aplicaba alguna de estas cosas, y las habría modificado si fuera el caso. Así que cada vez que ejecutas un generador o un script de migración, debes asegurarte de tener un historial de git limpio para poder revertir si algo sale mal. Pero esto me llevó a la última versión de NX. Y solucionó cualquier problema de código. Permíteme revertir eso porque en realidad no quiero estar en la versión 16.2.1. Entonces, hizo un pequeño cambio aquí. Eliminó este paquete react-test-renderer. Eso es lo único que cambió. Así que quiero mantener este, pero quiero deshacerme de todos estos. La razón por la que quiero hacer eso es porque las migraciones automáticas están configuradas en las migraciones para el taller en sí están configuradas con la versión 16.1.4, que era la última hasta ayer, o en realidad, hasta las 9 en punto de esta mañana. 16.1.4, y luego esto debe ser 16.1.4. Y luego volveremos a poner esto también. OK. Muy bien, así que voy a ejecutar Yarn nuevamente, solo para revertir todo. Y una vez que se hayan ejecutado tus migraciones, puedes eliminar el archivo de migraciones. Uno de los beneficios de tener el archivo de migraciones es que si estás en un repositorio más grande, a veces uno de los scripts generadores, scripts de migración, no funciona. Y así puedes estar en un estado intermedio, donde estos cinco se han ejecutado, pero el sexto no. Entonces puedes eliminar los primeros cinco y luego mantener el sexto en su lugar. Otra cosa que a veces sucede es que si tienes cien desarrolladores que hacen commit en el mismo repositorio, vas a tener algunos PR que aún están pendientes. Y has ejecutado todos los scripts en main, pero cuando se fusionan sus PR, debes ejecutar los scripts en su nuevo código que están agregando para asegurarte de que no se quede nada atrás. Así que a veces dejas el archivo JSON de migración para obtener el código que se queda atrás. OK. Permíteme mostrar las migraciones para el taller. Entonces, si generamos aquí, y el taller, voy a ejecutar el generador complete labs. Y solo quiero completar un solo laboratorio. Quiero completar el laboratorio 4 aquí. Y lo que hace esto, actualiza tu archivo migrations JSON para tener un script que simplemente completará el laboratorio 4. Así que puedo ejecutar NxMigrate --run migrations aquí, y eso completará el laboratorio 4 por mí. Debería haber confirmado en mi código. Hice exactamente lo que te dije que no hicieras. Y así el laboratorio 4 está creando esta biblioteca aquí. Así que permíteme revertirlo. Así que obtengo esto, y tendré esto. Descartar esos, y descartar esto. Y ese cambio. Así que voy a hacer commit de esto addMxReact. Lo otro que puedes hacer con este generador si quieres no solo hacer un solo laboratorio, puedes hacer desde esto hacia abajo. Puedes hacer del 1 al 4, y eso básicamente eliminará todo lo que has hecho y construirá todo hasta el laboratorio 4 si quieres hacer eso. Así que si alguna vez te quedas atascado, puedes hacer este paso. Permíteme volver a. OK, eso es para el laboratorio 13.1, o 3.1. Muy bien, ahora hagamos el laboratorio 4. Ejecutamos nx serve, creamos una nueva biblioteca react con el ejecutor nx rollup, creamos un nuevo componente react, y luego actualizamos el código, actualizamos este código. OK. Permíteme, voy a demostrar la aplicación NxGenerate. Entonces, si no especificas el complemento, te preguntará a qué complemento te refieres. Lo llamaremos UiShared. Y queremos que ya esté en el servidor. Será la carpeta store, la carpeta store. Entonces, para hacer eso, queremos tener --directory igual a store. Entonces, si ejecutamos eso, ¿fue eso sí? No, no necesitamos el enrutador para esto a la biblioteca URL, eso no es correcto. Debería estar yendo debajo de la carpeta libs. Eso es porque creaste una tendencia de aplicación, lo hice. Tienes razón, es por eso, gracias. Por eso, por eso, haces commit antes de ejecutarlo. OK, aquí va, ahora me está preguntando. Puedes crear una biblioteca JavaScript o una biblioteca React. Así que quiero que esto sea una biblioteca React y la prueba de ejecución está bien. Vamos a hacer roll up. Y lo ejecutaremos.

Bien, así que dejemos atrás estas carpetas pero podemos eliminarlas. Y esto es lo que esperaba. Tenemos una historia aquí, dentro de la carpeta store, tenemos la carpeta UIShare. Y podemos crear un nuevo componente React llamado Header dentro de esa biblioteca. Podemos hacer un componente exe y lo llamaremos Header. Y luego debería preguntarme dónde quiero que vaya. Vamos allí, debería ser exportado, sí. Y ahí vamos. Ahí está ese Header. Así que en lugar de copiar todo, voy a descartar todo esto y ejecutar la migración. Pero para copiarlo, irías aquí y copiarías este código. Hay otro código para copiar también. Supongo, no, eso es, sí. Este es el otro cambio de código que necesitas hacer. Usa el Header en tu app.tsx. Pero eso es solo cosas de React. Y todos ustedes ya conocen React. Así que vamos a ejecutar esto, hagamos un. Generar workshop revabs, para, ejecutar eso. Y nxmigrate, ejecutar migraciones. Así que aquí tenemos el archivo Header, el componente Header que hicimos antes con el código copiado. Tenemos, se está exportando aquí desde index.ts en la carpeta store. Después de tsx, está importando el Header aquí. Así que aquí estamos usando el alias at BG horde slash store slash ui shared, y luego el Header se está insertando aquí. Y así que si hago NX serve store, deberíamos ver un Header. Actualicemos esto. Aquí vamos. Aquí está nuestro Header. Genial. Bien. Ahora veamos el gráfico para ver cómo se relacionan estos proyectos entre sí. De acuerdo. Haz clic en Mostrar todos los proyectos. Y puedes ver que la aplicación store depende de la biblioteca. Genial. Y puedes ver que esto está sucediendo aquí. Permíteme modificar un poco de código rápidamente. Si comentara esto, comentara esto, y ejecutara el gráfico de índice nuevamente, puede ver que la dependencia ya no está porque ya no se está importando. Así que esto es completamente dinámico, completamente basado en tu código, lo cual es genial. ¿Preguntas al respecto? Estoy revisando Discord, nada en Discord. Muy bien. Sigamos adelante. Estamos en, de acuerdo, 15 minutos. Hagamos un laboratorio más, y luego tendremos nuestro descanso. Hagamos, oh, bien, de acuerdo, así que hemos terminado con las diapositivas. Hagamos el laboratorio cinco. Hagamos, sabes qué, hagamos, así que el laboratorio cinco es crear una biblioteca de utilidades usando NxJS en lugar de NxReact. Hagamos el cinco y el seis, y creo que el siete también es bastante sencillo. Pero saltemos adelante. Voy a ejecutar estos para llegar a cosas más interesantes más adelante, si eso está bien. Si te opones, sé vocal ahora. Básicamente, cinco, seis y siete están creando, cinco y seis están creando dos bibliotecas más, y luego siete está creando otra aplicación, una Express API. Así que voy a saltar adelante y solo haré una descripción general de lo que hacen esos diferentes laboratorios. Así que esto fue el laboratorio 4. Y voy a generar, hagamos del 5 al 7. Ejecutemos eso. Ejecutemos eso. Y hagamos NxMigrate. Ejecutar Migraciones. Permíteme ver algunas de las cosas clave que están sucediendo aquí. Lo principal que hace este es usar NxJS en lugar de NxReact. Así que esta es una biblioteca JavaScript simple. No importa React en absoluto. Pero aparte de eso, es lo mismo. Esta es una biblioteca de enrutamiento. Así que esto está usando la biblioteca NxReact, pero está utilizando el enrutamiento principal. Así que agrega automáticamente una ruta al app.tsx principal. Solo tienes que modificarlo más tarde, pero te da el valor predeterminado. Y luego el laboratorio siete, estás instalando un nuevo complemento NxExpress, y luego creando una aplicación con eso. Pero aparte de eso, es todo lo mismo que hemos estado haciendo.

Permíteme repasar cada uno de estos. Así que aquí se creó la API. Se utiliza un NxJsNode para ejecutarla. Y esta es una aplicación Express con un archivo main.ts que tiene algunas rutas aquí. Y copiamos el archivo fake API.ts que se ha movido aquí al lado del servidor. Pero básicamente es el mismo código. Eso es lo que está sucediendo aquí.

Aquí tenemos el mismo header que creamos antes. Ups, no quería hacer eso. Esto utiliza la biblioteca util, la biblioteca formatter aquí. Y esta es la ruta que se generó automáticamente para nosotros. Y esta es la ruta que se generó automáticamente para nosotros. Y luego aquí dentro de util formatters está el. Así que aquí, formato de calificación aquí. Ahí es donde se está utilizando. Y luego el formato de calificación se define dentro de util formatters. Y luego feature game detail es una ruta donde puedes hacer clic, obtener más detalles sobre un juego específico. Así que déjame ejecutar esto. Voy a servir la tienda aquí. Actualizar esto. OK, así que la única diferencia que puedes ver es que la calificación ya no tiene tantos decimales. Y si haces clic en uno de estos, muestra algunos detalles y la URL está cambiando. En nuestro próximo laboratorio, vamos a conectar realmente esta API. Así que en nuestro próximo laboratorio, en el laboratorio 8, vamos a conectar realmente la API y la aplicación de la tienda en el front-end y mostraremos cómo funciona. Esto es en realidad un poco más complejo que simplemente generar código y copiarlo. Sí, Perkup está preguntando sobre las dependencias circulares dentro de NX. Sí, en general, no quieres tenerlas. Es posible. Hay una regla de lint que las bloquea, pero puedes desactivar esa regla de lint si es necesario. Pero en general, si tienes dependencias circulares, como dos bibliotecas que dependen una de la otra, probablemente quieras reorganizar un poco el código para evitar ese caso. Entonces, en general, quieres combinarlas en la misma biblioteca o sacar algo de código de la biblioteca 2 y ponerlo en la biblioteca 1, algo así.

El laboratorio 8 está conectando la aplicación del front-end con la aplicación del back-end utilizando llamadas de red reales. Así que hagámoslo. Movemos la API falsa fuera de la aplicación de la tienda. Permíteme hacer un commit de esto. Es 5, 3, 7. Lo siento. Siempre tengo que buscar en Google cómo matar un proceso en un puerto. Ahí está. Eso es lo que quiero. Quemado. ¿No es bueno eso? Ahí está. Así que ahora comenzamos con el laboratorio 8. Eliminar la API falsa de la aplicación de la tienda. Creo que eso ya está hecho. No está hecho. Así que eliminar eso. Utilizar Fetch y Use Effect en el componente FF86. Así que vamos. Copiar eso. Y vamos a ver. ¿Dónde está el Fetch? ¿Dónde está el Fetch? Creo. Solo guarda eso. OK. Y luego es eso. Creo que eso es todo. OK, luego vamos a servir la API y servir la tienda. OK, necesito deshacerme de estas advertencias aquí. La API se encuentra en el puerto 3,000. Agrega una nueva terminal, NX serve store. La tienda está en el puerto 4,200 y la API está en el puerto 3,000. Ahora, si volvemos aquí, veamos si funciona. Actualizar. Algunos CSS están haciendo cosas extrañas, pero tenemos una pestaña de red aquí. Y actualizar. Todavía estoy jugando. Ahí está. Eso es lo que quiero. Creo que tengo una configuración para, sí, no quiero conservar el registro. Eso es lo que quiero.

Ahí vamos. OK. Está realizando una llamada a juegos. Dos llamadas a juegos. Realizando una llamada a juegos para, y esto va a la API de juegos en el puerto 4200, que se redirige. Así que esto es algo que omití. Debería volver a eso. Permíteme volver al laboratorio 7 aquí. En el laboratorio 7, debes asegurarte de establecer el front-end de la aplicación en store. Así que cuando creas la, cuando se, cuando se genera la aplicación Express, la aplicación Express API, creo que es --front-end. Generar la aplicación Scress y ¿dónde está? Proyecto front-end. Así que --proyecto front-end. Establecer eso en store. Y lo que hace es crear este archivo de configuración JSON de proxy, que configura automáticamente la redirección para que puedas servirlo localmente. Y el local host 4200 de la tienda redirige cualquier llamada a API a localhost 3000. Así que llegará a esta API servida localmente aquí. Así que si detuviéramos la API y actualizara esto, no se cargará nada porque no pudo obtener los data porque la API no se está ejecutando. Así que de eso se trata, de esta configuración de proxy. Y luego en el proyecto JSON, se hace referencia a ella. ¿Dónde está? Veamos. Ahí está. En el servidor, dice, eh, aquí es donde se encuentra la configuración de proxy. Así es como está configurado todo eso. Así que eso es todo. Así que adelante de nuevo al laboratorio 8. Servir allí. Servir allí. Todo debería verse igual. Esto habla sobre la configuración de proxy dentro de Libs. Ahora vamos a actualizar algunos de estos archivos para que la vista detallada se vea mejor. Característica de juego de la tienda. Esto está en las bibliotecas. Característica de juego de la tienda. Guardar eso y luego css aquí. Actualizar eso. Así que en la característica de juego de detalle, estamos usando este formato de calificación nuevamente aquí. Así que está importando desde la biblioteca util formators para usar esa función de formato de calificación. Lo haremos. Y vamos a ver, creo que aún debería estar sirviendo. Módulo de detalle del juego. Oh, es punto css en lugar de punto scss. No, eso está bien. Tal vez solo necesito reiniciar el servidor. Detalle del juego, detalle del juego, oh, el nombre es diferente. Es característica de juego de la tienda. OK, ahora si hago clic en esto, hay algunos detalles más bonitos para ti aquí con un botón de compra y compartir. No hacen nada. OK, eso funciona. Y ahora si miramos el gráfico NX aquí, también podemos ver que todas estas bibliotecas que hemos creado están conectadas. La tienda utiliza el Detalle del juego y la biblioteca compartida de UI, y ambas utilizan util formatters. En realidad, la tienda utiliza util formatters, y ahora la tienda utiliza util formatters. En realidad, la tienda utiliza util formatters, pero UI compartida no lo hace. Ahora, si te das cuenta, nuestra API está, en lo que respecta al gráfico, totalmente desconectada de la tienda. Así que NX no conoce ninguna relación entre ellos, y eso es lo que vamos a ver en nuestra próxima aplicación, en nuestro próximo laboratorio. ¿Qué fue eso? Así que en nuestro próximo laboratorio, queremos compartir algunos tipos entre el front-end y el back-end, básicamente como un contrato para lo que devolverán las llamadas de red. Así que si eso cambia en algún momento, entonces debes asegurarte de actualizar ambos lugares para tener en cuenta cualquier cambio en la nueva API. Así que las detenemos. Generaremos una nueva biblioteca de JavaScript llamada util interface y la pondremos dentro de la carpeta API de las bibliotecas. Más adelante, la moveremos, pero vamos a comenzar en una carpeta API y luego te mostraremos cómo hacer el movimiento más adelante. Esto fue el laboratorio ocho. Y ahora vamos a trabajar en el laboratorio nueve. Disculpa, déjame revisar rápidamente Discord. Sí, FreeTest, sí. La API puede estar en cualquier cosa que desees. En Flask o en un marco de trabajo de Python. Sí, así que no hay nada que te impida poner otros lenguajes en un monorepo indexado. Hay complementos. Entonces, las cosas que los lenguajes que no son JavaScript no tienen por defecto en un monorepo indexado es el entendimiento automático del gráfico. Permíteme mostrarlo aquí. En realidad, supongo que es NxJS, creo.

NxCore tiene la capacidad de analizar código TypeScript o JavaScript para comprender y dibujar automáticamente estas dependencias. Para otros lenguajes, es necesario utilizar un complemento para obtener ese soporte automático. Algunos lenguajes tienen un complemento que lo hace por ti, mientras que otros aún necesitan ser desarrollados, pero de alguna manera es necesario analizar el código en ese proyecto y determinar cómo se relacionan entre sí estos dos proyectos de Python. Algunos lenguajes tienen una forma de analizar las declaraciones de importación o cualquier otra forma que el lenguaje tenga para dibujar estas dependencias. Pero aparte de eso, NX puede hacer todo por ti. También puedes crear manualmente tus dependencias, pero eso obviamente no cambiará cuando el código cambie. Debes actualizar las dependencias tú mismo de esa manera. Sí, eso responde a esa pregunta.

Luego, la pregunta de Ben. Tenemos un proyecto NX que contiene muchas bibliotecas y aplicaciones. ¿Cómo anular la biblioteca específica de Google, pre-commit one, si los archivos cambian para un compromiso? No... Sé que uso Husky. No he escrito muchos ganchos pre-commit yo mismo. Déjame pensar... Si los archivos cambian para una biblioteca específica... Sí, básicamente lo que harías, Ben, es en tu gancho pre-commit, ejecutarías el comando NX affected con el objetivo que desees. Y ejecutaría esa tarea, ese objetivo, para todas las bibliotecas que se vean afectadas por el cambio. Sí, definitivamente puedes hacer eso. Sí. Bueno, volvamos. Creo que he respondido esas preguntas. Y volvamos a donde estábamos. De acuerdo. Nuestro objetivo ahora, en el laboratorio nueve, es crear una nueva biblioteca de tipos y usarla tanto en la API como en la tienda. Muy bien, vamos a crear una biblioteca llamada util interface dentro de la carpeta API. Ahí. Vamos a pegar esto. De acuerdo, generar biblioteca NX y la llamaremos util interface y la pondremos en la carpeta API. La haremos una biblioteca JS. Está bien. Está bien. Muy bien, debajo de la carpeta API, tenemos util interface y API util interface está aquí y copiamos este código. De acuerdo. Es una interfaz de juego para nosotros y la importaremos en el archivo gamesrepository.ts. Básicamente, esto será un array de juegos. Y el servicio API, vamos a construir el API NxBuildAPI, asegurémonos de que no se haya roto nada. Si te fijas, cuando hice la compilación del API con NX, hizo la compilación de las tareas de los proyectos dependientes. Lo que sucedió fue que si miras el gráfico NX nuevamente, cuando compilo este API, vio que tengo un util interface que también tiene un comando de compilación y dice que voy a ejecutar la compilación de esto antes de ejecutar la compilación de esto. También puedes ver esto visualizado por tarea y mostrar todas las tareas de compilación aquí. Sí, la compilación del API depende de la compilación de util interface del API. Así que puedes ver que esto siempre se ejecutará antes de que ejecutes eso. Veremos cómo funciona esto. De acuerdo, eso es todo y ejecútalo, inspecciona el gráfico de dependencias, bien. Nos piden que hagamos commit de todo, de acuerdo, lo haremos. Esto es el laboratorio nueve, parte uno. De acuerdo, ahora lo usaremos en el frontend. Tenemos esto data aquí en app.tsx. Así que arreglemos eso. Usamos la interfaz de juego real aquí. ¿Por qué no está, hola? Comporch, eso no se ve bien. De acuerdo, lo arreglaré. De acuerdo, así se arregla poniendo el juego aquí. Pero esto se ve extraño aquí. No queremos importar desde la carpeta API dentro de la aplicación de la tienda. Esto no se ve bien. Así que movamos esto, esta util interface, fuera de la carpeta API y coloquémosla en el nivel superior. También podríamos ponerla en shared, pero para este taller la pondremos en el nivel superior. Así que usaremos el generador de movimiento para mover esa biblioteca a una nueva ubicación. Haremos esto. Generar, mover. También puedes hacerlo completamente desde la línea de comandos si no quieres hacer clic allí. Puedes hacer generar, y X generar, y buscar mover. Mis dedos no están dejando el teclado en absoluto. Mover, y vamos a seleccionar el nombre del proyecto.

Este no tiene autocompletado. No me gusta eso. Bueno, API, util interface es el nombre de la biblioteca. Y luego lo vamos a mover a solo util interface. Para sacarlo de la carpeta API y llevarlo a util interface. Y probemos eso. Ejecútalo. Veamos qué sucedió. Se movió a libs util interface. Eso parece correcto. Solía estar bajo /API util interface, y ahora es solo util interface. Así que eso parece correcto. Ahora veamos nuestro repositorio de juegos aquí. Este código se actualizó, por lo que ahora es correcto, y el archivo app.tsx aquí, este código también se actualizó. Entonces, en todas partes donde se usó también se actualizó. Es realmente útil. Donde se hayan utilizado las cosas, se actualizarán automáticamente. Y también tu tsconfig, esto obviamente también se actualizó. En lugar de /API, /user interface, ahora es solo /user interface. De acuerdo. Elimina esa importación. Oh, esto está mal formateado, lo siento. Pero ya lo hice en TSX. Y en la característica de detalle del juego, también quiero actualizar eso. Y data en a, esto debería ser data, creo. Sí, no sé por qué esto. Aquí, voy a actualizar TypeScript, reiniciar el servidor de TypeScript. A veces el servidor de TypeScript necesita un poco de ayuda. Ahí vamos. Data. Oh, y creo que es un juego parcial. Permíteme ver qué se suponía que debía ser. Sí. Juego parcial. Muy bien. Ahora me está ayudando a obtener la señal que quiero, así que eso es suerte. Me ayudó. De acuerdo. Ahora está satisfecho con este objeto vacío aquí. De acuerdo. Eso funciona aquí, entonces podemos, uh, construir tanto la API como la tienda, verificar el gráfico de dependencias. Next build store. De acuerdo. Eso funcionó, next build API todavía debería funcionar. De acuerdo, genial. Y veamos el gráfico. Ahí vamos. Así que util interface está siendo utilizada por la tienda, la característica de detalle del juego y la API. Por lo tanto, cada vez que cambie esta interfaz de utilidad, estos tres lugares se actualizarán. Genial. Obviamente, si se utilizan diferentes lenguajes, no se podrán compartir tipos de esa manera. Pero en ese caso, lo que haría es agregar un borde manual aquí. Y la forma de hacerlo es, supongo que probablemente lo harías desde el frontend hasta el backend. El archivo project JSON de la tienda aquí, y agregarías una dependencia implícita en la API. Y luego, si vuelves a mirar el gráfico, Actualízalo. Sí, entonces la tienda tiene una dependencia implícita en la API. Entonces podrías hacerlo de esa manera si tienes una API escrita en un lenguaje diferente. Y quieres asegurarte de que haya una conexión entre las dos. A veces puedes prescindir de esa conexión por completo. Pero depende de ti cómo quieras estructurar las cosas. De acuerdo, preguntas de esta parte. Creo que está bien. No hay nuevas preguntas en este canal. De acuerdo, lo voy a confirmar. Laboratorio 9. laboratorio 9. Y el próximo laboratorio es más corto. Pero muestra el poder de los generadores y las cosas que se pueden hacer con los generadores si eres un poco ingenioso con la forma en que los usas. Y vamos a generar algunas historias de storybook para componentes. Oh, esto se va a poner, espera.

Entonces, cuando hagas esto, asegúrate de que las versiones aquí estén sincronizadas. Sí, debería ser 16.14, no 16.21. Así que acaban de publicar la versión 16.21 mientras se llevaba a cabo nuestra masterclass. Por eso está desincronizado. Así que si vas a ejecutar esto, asegúrate de poner 16.14 aquí.

Vamos a usar el generador de configuración de storybook para crear algunas historias. Configurémoslo, ¿para qué proyecto lo hacemos? Para el proyecto compartido de UI. Generemos la configuración de storybook. Eso es lo que queremos. Y luego queremos hacerlo para UI compartido de la tienda. Y esto es solo una prueba en seco. Vamos a marcar todas estas casillas o simplemente decir sí a todas estas preguntas y ejecutarlo. Y esto crea estos archivos, actualiza algunas cosas, crea un archivo de historias. Crea un archivo de historias dentro del componente de encabezado o junto a él. Ya llegaremos a eso más tarde. Historias de UI compartido aquí. OK. Historias. Y. Oh, eso es lo otro. Eso es algo que no hice. No configuré una entrada para esto, por lo que el generador no encontró ninguna entrada y no creó perillas automáticamente en la historia. Permíteme. Permíteme hacer esto rápido. Título de cadena, deshacer lo que acabo de hacer. Sí, puedo hacer todo esto. Voy a deshacer eso y luego lo volveré a hacer más tarde. Agregar un título, y eso es una cadena. Y. Y hagamos que sea opcional. Tal vez ese título o. Hacer eso. Y eso debería ser todo. OK. Hacer eso, y luego ahora vamos a ejecutar ese script del generador nuevamente. OK, aquí vamos. Así que reconoce que había una entrada allí, una prop que se pasaba. Y por eso creó una perilla para ti en storybook. Y listo. Veamos y verifiquemos una vez que termine de instalar las dependencias. Vamos a servir storybook. OK, parece que terminó. Está bien. Dentro de aquí, agregó un nuevo objetivo. Prueba, aquí vamos. Next storybook. Entonces vamos a llamarlo NX storybook, UI compartido de la tienda. ¿Qué está pasando? Oh, eso está usando beat como predeterminado. Creo que voy a tener que retroceder de nuevo, creo. OK. Voy a expandir esto y creo que el predeterminado ahora es Vite. No, ¿dónde está? Debería haber una configuración aquí. Sí, configuración base de TypeScript. Hm. Bien, veamos esto. Eso está usando eso. Configura un punto storybook. Sí. Veamos. Esto necesita pre-react Webpack, creo. Como lo tenemos, lo tenemos configurado con Webpack. O, oh, ya sé qué es. Creo que esto no está instalado.

Ese es el problema. No construir o configurar, sí. Packages JSON en storybook slash React feed. Oh, no, está ahí. Tal vez no he ejecutado el brazo. No, no está ahí. No. ¿Esto tiene? Sí, ahí vamos. Bien, voy a, No estoy seguro cuál es el problema con eso, pero voy a intentar cambiar esto solo a React. Bien, no le gusta eso. Oh, okay. Así que eso debería estar ahí. Y esto debería estar aquí. En ese módulo encontrar batir, okay. Bien. Creo que ese es el problema. Creo que necesitamos instalar beat. Yarn, y, sí, okay, ahí lo tienes. Eso es mejor. Okay, aquí está Storybook. Y tenemos el encabezado con algunos, Diría que no hay opciones aquí. Bueno, entonces está renderizando nuestro, renderizando nuestro componente aquí con estas opciones predeterminadas, que es el juego de mesa Hoard. Y ha pasado un tiempo desde que trabajé con Storybook, pero hay una forma de configurar esto para tener un, como un cuadro de texto que puedes completar y cambiar la, cambiar la entrada dinámicamente, la prop dinámicamente. Así que ARGs. Bueno, no voy a hacer esto en vivo. Pero esto configura Storybook para ti y también puedes configurar pruebas de Cypress que se ejecutan en Storybook. Esa es la siguiente práctica, que no tenemos que seguir paso a paso. Pero en ese generador, esas casillas que recorrí. Esta. Esta casilla y esta casilla generan especificaciones de Cypress para cada historia. Esta historia de prueba de UI compartida ETE es una prueba ETE, pero es una prueba ETE solo para el componente. Está testing de la forma en que lo haría un usuario, como a través de Storybook, pero solo es ese componente aislado. Se está ejecutando Cypress en esa instancia de Storybook, haciendo clic en ella y realizando las acciones que desees hacer solo en ese componente específico. Voy a los límites del módulo. Cada proyecto tiene una propiedad de etiquetas aquí. Digamos que tienes un proyecto de repositorio que está configurado así. Tienes dos aplicaciones en la parte superior y dependiendo de las bibliotecas dentro de ellas, pueden ser Angular o React, cualquier marco que estés usando. Quieres tener algunas reglas que digan que esa biblioteca de ventas no puede depender de la biblioteca de juegos. Porque los juegos son específicos de la tienda y el código de administración no debería usarlo. Puedes agregar etiquetas a las cosas. Las etiquetas son solo cadenas. Cualquier cadena que desees. La convención es hacer algo como una especie de categoría primero y luego dos puntos y luego el valor específico para esa categoría. Entonces tenemos tipo app y tipo feature, tipo util. Y luego puedes tener un alcance. Puedes decir que el alcance es como el al que pertenece la aplicación, básicamente. Entonces tenemos alcance store para esas dos cosas y luego alcance admin para esos tres proyectos allí. Y luego alcance shared para las cosas en la parte inferior que todo puede usar. O, sí, alcance core. Alcance core y alcance shared son. Esencialmente lo mismo, así que no. No sé por qué usarías alcance core en lugar de usar solo alcance shared para todo, pero está bien. Pero entonces una vez que tomas todo, puedes establecer reglas para cómo estos proyectos con estas etiquetas pueden depender entre sí. Puedes decir que cualquier cosa con la etiqueta de tipo app solo puede depender de tipo feature y tipo util. Entonces un tipo app no puede depender del tipo app, ¿verdad? Puedes establecer esta otra regla. El tipo util solo puede depender del tipo util, por lo que te bloquea de un tipo util, dependiendo del tipo feature. Puedes establecer una regla para que el alcance store solo dependa de alcance store o alcance shared o alcance core, y eso te impide tener un alcance store que dependa del alcance admin. Entonces con esta configuración, eso le da una estructura a estas cosas y te permite evitar que ese proyecto de ventas dependa del proyecto de juegos porque el alcance admin no debería depender del alcance store. Solo debería depender de alcance shared u otros alcances admin. Correcto, eso es lo que dice esta regla. Aquí, el alcance admin no puede depender del alcance store. Así que eso lo bloquea. Sí, vamos a, um. Hagamos eso.

Entonces, en project.json, esta propiedad de etiquetas es donde defines cuáles son las etiquetas. Y así, agreguemos estas etiquetas a. Alcance store y alcance tipo app. Así que ese es el proyecto store. Proyecto. OK, simplemente vamos a pasar por cada. Archivo json de proyecto de esa manera. Y actualizar las etiquetas. Aquí están las etiquetas. Así que esto es alcance store y tipo app. Correcto, API. Las etiquetas están aquí abajo. Esto no es alcance store, esto es alcance API, pero también es tipo app. Y son los otros archivos json de proyecto. OK, esto es. Las etiquetas ahora aparecen. Así que esto es alcance shared, así que esto es alcance shared. En realidad, no, esto es alcance store. Aunque tiene 'shared' en el nombre. En realidad, es alcance store. Y esto es tipo UI. Proyecto JSON, así que e e. OK, no hay etiquetas aquí, así que tenemos que editar las etiquetas. Le daremos un alcance de ETE, supongo. Y. No tipo. ETE Ahora supongo que esto sería alcance API y tipo ED. Este es el ETE de la API. Dicho esto y luego. Sí, gracias. Esto es alcance store y tipo ETE. Proyecto JSON. Interfaz util. La interfaz util es alcance shared. Y tipo util. Y tipo util. Esto es alcance store. Y tipo ETE. ete. Formateadores util. Sí, esto es alcance store. Y tipo util. Y un proyecto más por hacer. Característica del juego de la tienda. Así que alcance store y tipo feature. Muy bien, ahora hemos aplicado etiquetas a todo. Los nueve proyectos aquí. 1, 2, 3, 4, 5, 6, 7, 8, 9. Sí, ahora volvemos a las instrucciones. Y vamos a ver el archivo eslint. Y vamos a modificar el cumplimiento de los límites del módulo para agregar algunas reglas. Así que voy a copiar esto como punto de partida. Muy bien, cumplimiento de los límites del módulo. Genial. Por defecto, tiene esta regla aquí, que dice que cualquier cosa puede depender de cualquier cosa. Si eliminaras esta regla, aquí, déjame ejecutar lint tal como está. Puedes usar nx run many para ejecutar múltiples objetivos al mismo tiempo. Entonces nx run many con un objetivo de lint, y luego puedes especificar una lista de proyectos por nombre, o simplemente puedes, si no especificas proyectos, hará todo. Esto está ejecutando lint en todo. Todo pasó. Si eliminara esto, entonces nada pasaría. ¿Oh, no? OK, supongo que eso solo dice que está bien. Así que nada es lo mismo que esa regla predeterminada. Así que aquí tenemos esta regla que dice que alcance store solo puede depender de alcance store y alcance shared. Permíteme ejecutar Lint rápidamente aquí. OK, aquí vamos. Ya tenemos un problema con API. Así que API depende de esta interfaz util. El problema aquí es que no hemos enumerado completamente. Cualquier cosa que no cumpla una de estas reglas generará un error.

Entonces, cualquier cosa que no sea alcance store y dependa de algo mostrará un mensaje de error, diciendo que no cumple una de estas reglas y, por lo tanto, falla. Así que tenemos que definir completamente todas estas reglas. Podemos agregar alcance API que depende de eso, o alcance shared y luego el tercero es alcance shared que solo puede depender de alcance shared OK Así que eso establece eso Esas son todas las reglas de alcance Y ahora, si ejecutamos lint, todo debería pasar Oh, tengo una coma aquí, tal vez Sí, es una lista OK Así que ahora todo está pasando, pero estas son solo las reglas de alcance Así que vamos a hacer lo mismo para las reglas de tipo Entonces tenemos tipo Vamos a hacer tipo feature, ¿es así como lo llamé? No, déjame ver feature game detail Tipo feature, sí Solo puede depender de otras bibliotecas de características Puede depender de tipo util Puede depender de tipo UI Y luego también podríamos agregar tipo data access pero no tenemos ninguno de esos por ahora Y luego podemos hacer tipo UI, no se permite depender de feature pero util está bien y otro UI está bien Así que vamos a obtener eso Y luego tipo util solo puede depender de tipo util Vamos a copiar esto y hacer lo mismo para app Tipo app Entonces, si eliminara esto y no lo tuviera aquí entonces diría que la app podría depender de cualquier cosa Pero no queremos que las apps importen otras apps, lo cual es en realidad las apps no tienen un alias creado para ellas Así que no pueden depender entre sí de todos modos Pero sí, esto lo hace explícito, supongo Sí, creo que eso es todo Esa es una coma muy rápida Y déjame verificar, terminar de configurar esas reglas y Nx run many Vamos a ejecutar esos niveles nuevamente OK, eso pasó todo Ahora veamos, hagámoslos fallar Así que vamos a copiar esto Y en el archivo de encabezado, vamos a importar desde feature game detail Así que debería romper esto El tipo UI no debería poder depender del tipo feature Así que vamos a agregar una declaración de importación aquí arriba Así que ya está mostrando un mensaje de error Ahí lo tenemos, la regla de lint ya está fallando en línea en el editor, porque el proyecto etiquetado con tipo UI no puede depender de util o UI Y si ejecutamos lint, y si esto se subiera a CI de alguna manera fallaría en el paso de lint, porque esto fallaría Así que eso maneja eso Y también podríamos verificar algunas de las otras reglas si queremos Si queremos límites entre alcances así que detengamos a la API de importar el formato rating de format util Así que vamos a ir a main.tsx, main.ts e importar aquí Lo mismo Pero el alcance API solo puede depender del alcance API y shared No puede depender del alcance store No está permitido No puedes hacer eso Así que esto es bueno En un repositorio más pequeño, podrías encargarte de esto solo haciendo PR y revisando PR Pero en un repositorio mucho más grande, eso se vuelve insostenible y no puedes mantenerlo Así que tener una computadora que lo haga por ti es genial Así que si ejecuto un lint nuevamente, todo pasa Todo pasa muy rápido porque todo está en caché Muy bien ¿Preguntas? ¿Otras cosas que quieras que cubra? Así que está en caché porque en NXJSON especificamos lint como una operación cachable Y por defecto, se almacenará en caché Muy bien Quedan cuatro de ustedes Podemos hacer algo muy específico a lo que te interesa ¿Preguntas ahora? Sí Ha sido muy interesante Creo que si tenemos tiempo, hablaré sobre CI.

Sí. Pero no sé acerca de los demás. Sí, podemos hacerlo. Entonces, CI, ¿nos adentramos en la configuración de la caché local primero, o quieres ir directamente a configurar el CI utilizando el comando efectivo en CI y hacer eso? Sí. ¿Por qué crees que es más general? Porque estoy empezando con NX. Y quiero usarlo en uno de mis proyectos, que se está volviendo bastante grande. Así que creo que es una buena idea para un proyecto. Así que parece muy útil para obtener más una cosa de arquitectura. Porque lo tenía cuando usaba Angular, pero ahora que estoy en este proyecto de React, me falta todo este alcance. Así que ahora tenemos un entorno más controlado. Sí. Muy bien. Así que hagámoslo. Así que solo para que sepas, todo este contenido está aquí. Son todos estos. Veamos. Así que configurando hoy, veo el laboratorio 15 aquí. Así que podemos adentrarnos en eso. La otra cosa que también es útil, los generadores locales de espacios de trabajo y no los generadores de espacios de trabajo. Eso es muy útil en un entorno grande para configurar la creación automática de cosas y modificar los generadores que se te proporcionan para usar las banderas que siempre usas en tu repositorio. Pero vamos a omitir eso. Muy bien, entonces adentrémonos en la configuración de CI. Muy bien, para hacer esto, primero necesitamos, necesito subir esto a un repositorio en GitHub. Debo ser el 13, creo, no lo sé. No, creo que era el 12, pero no importa. Necesito subir esto a un repositorio en GitHub. De acuerdo, aquí vamos. Esta es una configuración. En realidad, este es un taller anterior en el que trabajé, así que voy a descargar esto porque será más rápido. No quiero espacios de código. Local, eso es mejor. Muy bien, voy a eliminar eso. Dividamos esto. Luego revisa el otro. De acuerdo, eso es, eso es. Entonces, esto, tiene la misma API. Oh, esto es, así que esto usaba una configuración de nodo en lugar de react, pero eso no importa para CI. De acuerdo, tengo un CI.yaml aquí. Muy bien, tengo un CI.yaml aquí y está configurado con, así que inicialmente, configurarías tu CI.yaml con algo como esto potencialmente donde tienes, pruebas una cosa y luego pruebas la otra cosa, pero la forma más eficiente de hacerlo es hacer, en lugar de probar explícitamente la API y probar explícitamente la store, es simplemente decir, ejecutemos pruebas para todo lo que fue afectado por la PR. Y hay un cambio que debo hacer aquí en el CI aquí. Acciones de GitHub. Siguiente, reviso. Esto es lo que quiero. Eso es lo que quiero hacer. Pasos de revisión, sí, está haciendo eso. Resolver esto. Pasos de revisión, sí, esto es lo que quiero. Usa eso y luego ejecuta el VPCI. De acuerdo, entonces, lo que hace Efectivo es, supongo que no lo he demostrado, ¿verdad? Permíteme, permíteme ocultar esto, ocultar eso. Digamos que hago un cambio aquí en esta API. Puede ser un cambio real o simplemente un cambio de comentario y luego hago nx affected --target=test. ¿Qué está pasando? Oh, olvidé instalarlo. De acuerdo, esto ejecutará pruebas solo en esa API porque puede ver que cambié esto y no hay nada que dependa de ello. Si miro el gráfico de NX. Entonces este es un repositorio ligeramente diferente. Permíteme mostrarte cómo se ve el gráfico aquí. La API solo tiene las pruebas ETE que dependen de ella y nada más. Así que hice este cambio aquí y nada más puede verse afectado por él. Si cambio la API auth, debería ejecutar pruebas en esto, en API auth y API. Entonces, si entro aquí, y libs, API auth, permíteme hacer un cambio aquí. E incluso podría eliminar este cambio aquí. Y ahora ejecuto NxEffected. Ahora se ejecuta en API auth y API. Las pruebas fallaron, pero no nos importa eso. Sí. Sí, está bien. Sí, eso es lo que hace Effected. Puede ver qué se cambió y ejecutar los comandos solo en esas cosas. Entonces ahora, si yo, voy a deshacer estos cambios aquí. Entonces, en este CI, lo tengo configurado para revisar nuestro código y con esta profundidad de búsqueda cero, porque quiero asegurarme de que también verifiquemos la, no podemos simplemente verificar la confirmación que se está probando. También tenemos que verificar la confirmación base, la confirmación anterior, porque NX necesita comparar los dos conjuntos de archivos diferentes.

Así que eso es, de lo contrario, el comando NX effective no funcionará porque no tiene nada con qué comparar. Permíteme subir eso. Subir eso y voy a ver, en realidad lo que hay en main. De acuerdo. Vamos aquí. Y vamos a ver. De acuerdo, voy a hacer una nueva PR aquí. Y hagamos esto. Hagamos, hagamos esto en nuestra API auth aquí. Llámalo cambios realizados. Y vamos a darle una nueva rama. Y luego subir la PR aquí. Estoy seguro de que está bien. Y así se ejecutarán las comprobaciones de CI. Veamos qué hace. Así que se está ejecutando, comprobando. Configurando Shaz, está haciendo NPMCI, que es la instalación de NPM, pero solo los paquetes que se necesitan para CI. Obtener rama, solo rastrear, nombre de origen. Eso está bien, se está ejecutando el objetivo de prueba. Pudo determinar que necesita ejecutar pruebas en API auth y API. Simplemente falló en la prueba, como esperábamos. Lo sabía porque solo hicimos cambios en este archivo en particular aquí, solo necesitábamos ejecutar pruebas para API auth y API en lugar de tener que ejecutar pruebas para todos los demás proyectos en el repositorio también. Así que esos son los conceptos básicos de CI aquí. También podríamos... También podríamos hacer cosas más complejas. Mayla y Pedro, ¿a dónde quieren ir desde aquí? Sí, quiero decir... ¿Vamos a profundizar en CI? ¿O estamos haciendo otras cosas? ¿O tienes preguntas sobre tu repositorio específicamente? No, solo estoy procesando toda esa información. Pero sí, mencionaste acciones y parece muy interesante para mi caso porque tengo muchos componentes que quiero... más o menos cuando tengo que agregar uno nuevo. Tengo un documento con todos los pasos y creo que podría hacerlo con una sección siguiente lo cual sería muy bueno. Sí, lo generé, sí. Y, pero sí, quiero investigar y tratar de adaptarlo a mi realidad pero... Sí, sí. Mel, creo. ¿Fuiste tú quien tenía preguntas al principio sobre tu repositorio específico? Sí, tal vez si tienes algunos consejos. Sí. Porque nuestro propio repositorio era anteriormente uno de aprendizaje. Sí, está bien. Antes, sí. Así que siempre son paquetes. Así que no es integrado. Y me gustaría saber si es necesario migrarlo a uno integrado. Bueno, la única razón por la que querrías hacer eso es si quieres usar ejecutores, si quieres usar uno de nuestros ejecutores predefinidos que maneja cosas como webpack básicamente o cualquier otra cosa, veamos, déjame ver aquí. Eso es realmente lo único que no puedes hacer en un repositorio basado en paquetes. Algunos de los generadores en los complementos tienen una expectativa sobre la estructura de carpetas, pero eso depende de cada caso. Pero en realidad, lo único es si quieres usar estos ejecutores aquí, entonces necesitas tener un repositorio integrado, como tener un project.json en lugar de package.json. Pero eso es lo único que necesitas hacer. Pero si no necesitas eso, entonces no necesitas cambiar. Toda la caché seguirá funcionando. Aún puedes configurar una canalización de tareas y hacer que las compilaciones dependan de... La compilación de la aplicación depende de las compilaciones de la biblioteca u otras tareas dependen entre sí. Todo eso se puede configurar sin problemas. Puedo mostrarte eso rápidamente, de hecho. Si tenemos un... Vamos a hacer nxglib, y crear una biblioteca JS, y... Llamémosla simple. Está bien, está bien. Y vamos aquí. Simple, y voy a eliminar el project.json aquí. Y así que... Y así que voy a agregar un script aquí. Y construir, y decir echo... Hola. Y así que si ejecuto nx build simple, ¿dónde está? Lo ejecutó, pero creo que ocultó la salida. Eso no es simple. Tal vez otro verbose performance. Sí, tal vez. No sé. No he estado probando eso. Voy, hola. Si intento encontrar el símbolo del proyecto.

Vamos, creo que podría haber estado en caché. Oh, por eso se llama síntoma de BG horde. Hagamos eso. Ahí vamos, estaba en caché, no lo había recogido que lo había cambiado. Y ahora necesito reiniciar de nuevo. Siguiente construcción, texto json, el nombre es simple. Oh, eso es lo que es. Si estás usando package json, debes usar espacios de trabajo en la ruta. Espacios de trabajo, probablemente ya lo tengas configurado. Podemos hacer esto. ¿Así es como funciona? ¿Es un, es un array, verdad? ¿Es eso... Lib slash, algo. Esos grupos de espacios de trabajo- Ahí está. ¿Agrupar los proyectos, verdad? Entonces, estos espacios de trabajo aquí, no es un índice. Esto es, esto es ya sea npm o pnpm o yarn que tu administrador de paquetes tiene una forma de comprender que tienes otros, básicamente otros archivos package JSON dentro de tu repositorio. Y así, cuando ejecutas npm install, puede ejecutar la instalación para todos ellos. De acuerdo. Así que para eso es esto. Así que puedes buscar, ya sabes, yarn workspaces o npm workspaces. Típicamente, con un, creo que puedes hacer libs star, y eso buscará todo dentro de libs. Sí, eso aún funciona. De acuerdo, de todos modos. Esto está ejecutando el script NPM. Y luego aquí, digamos que quieres agregar alguna configuración a eso. Configuras la propiedad nx aquí. Y luego puedes decir, veamos, objetivos. Así que aquí puedes agregar etiquetas aquí, como hicimos antes con tu ámbito API o lo que sea. Y luego todas las demás opciones que puedes configurar aquí. Entonces, si entro en objetivos, si quiero establecer algunos valores específicos para el objetivo de construcción, entonces puedo ir aquí y establecer depends on, y hacer que dependa de aquí. Lo haré depender de la base de construcción. Y echo ejecutar esto primero. Así que aquí se ejecutó la base de construcción primero y luego se ejecutó la construcción debido a esta propiedad depends on aquí. Hay muchas otras cosas que puedes hacer con depends on. Puedes hacer que dependa de otros proyectos. O podrías decir también construir las dependencias. Ejecutar la tarea de construcción en las dependencias Eso es lo que significa este acento circunflejo. El acento circunflejo significa que para los proyectos dependientes, las dependencias de este proyecto ejecutan la tarea de construcción. Así que podría ser, no sé, ejecutar la prueba, pero eso no tiene mucho sentido. Pero puedes poner cualquier nombre que quieras allí. ¿Tiene sentido, Mayo? Sí. Sí. Creo que eso es lo que necesitan. Genial. Y así puede enlazar las dependencias de la misma manera que en uno integrado. ¿Entonces compila el código para conocer las dependencias? No. No de forma predeterminada. Si quisieras hacer eso, así que de forma predeterminada, en un repositorio basado en paquetes, se basa en tus dependencias que defines en tu archivo package JSON porque muchos, así que si tienes una dependencia aquí en bghorde API, creo que es, o es una barra diagonal? Creo que es una barra diagonal. Y luego un asterisco. Así que una dependencia en algo más que está dentro de este repositorio, entonces sabe que, OK, tienes una dependencia aquí. Si quieres, en lugar de usar esta dependencia, si quieres que el gráfico de dependencias use el código real, solo necesitas cambiar en nxjson aquí. ¿Dónde está? Aquí, lo buscaré en la documentación aquí. Um, qué, siempre tengo problemas para recordar con esta bandera. Source. Sí, el gráfico de dependencias creado a partir del análisis de archivos fuente. Eso es lo que es, analizar archivos fuente. Aquí, esto es lo que quieres. Lo pegaré en Discord. Entonces, la configuración de plugins debajo, debajo del angst.json. Así que en este repositorio en particular, ya está configurado como verdadero. Por defecto es verdadero. Pero en un repositorio basado en paquetes, por defecto, esto será falso. Así que si quieres que esto suceda para ti, entonces necesitas establecerlo como verdadero. De acuerdo. Y luego, lo que sucede es que cuando lo activas en verdadero en muchos repositorios, encontrarán dependencias entre cosas que no esperaba, lo cual tiene sentido. Pero luego podrías tener dependencias circulares en cosas que no pensaste que estaban allí, pero en realidad están allí. Oh. Así que quiero decir, creo que es mejor activarlo, pero las personas que solo quieren que las cosas funcionen pueden querer dejarlo desactivado. De acuerdo, creo que estamos llegando al final del tiempo. ¿Alguna otra pregunta? No, gracias, Isaac. De acuerdo. Sí, de nada.

Es divertido tener algo de tiempo para hacer preguntas individuales. Tal vez solo una última pregunta. Creo que he leído que es mejor tener menos bibliotecas y aplicaciones. No, es solo un compromiso. Entonces, déjame, también lo vincularé. Crear biblioteca. Hmm. Aquí vamos, este es el artículo. Así que es solo un compromiso aquí. Extraño, emoji genial. Básicamente, si creas una nueva biblioteca, cada biblioteca que creas es otro objetivo en caché. Como si tuvieras todo en una sola aplicación, tu caché se rompe con cualquier cambio que hagas, ¿verdad? Y tu gráfico es solo un nodo, lo cual no es muy útil. Pero cada vez que lo divides, si ejecutas affected, hay más potencial de que más código no necesite ejecutarse, ¿verdad? Más pruebas no necesitan ejecutarse porque se separan en bibliotecas que sabes que no se ven afectadas, ¿verdad? Eso es una ventaja de crear más bibliotecas. Y puedes establecer más restricciones, restricciones más razonables en cosas como, sé que estas cosas pueden depender entre sí, pero estas otras cosas no pueden. Entonces, por eso quieres tener más bibliotecas, pero luego, negativo, hay sobrecarga al crear más bibliotecas, por lo que puedes exagerar y crear miles de bibliotecas. Entonces no quieres hacer eso. Pero es solo un, hay pros y contras y solo quieres tener un número razonable. Y típicamente, para mí, si tienes más, si tienes un componente por biblioteca, eso es probablemente demasiadas bibliotecas. Pero un puñado de componentes está bien. Y básicamente, si vas a hacer un cambio, haz un cambio en cosas similares en la misma biblioteca. Si vas a hacer un cambio, todo lo que vas a cambiar debería estar junto en un solo lugar. Entonces es lo mismo que con los problemas de la estructura de carpetas. Tienes el mismo tipo de pros y contras. Si tienes más carpetas, puedes separar las cosas y organizarlas realmente bien, pero luego puede ser difícil encontrar cosas que vayan juntas. Sí, de acuerdo. Tiene sentido. Sí. Genial. De acuerdo, gracias a ambos. Y para todos los que están viendo en línea, viendo la repetición, gracias por quedarse hasta el final de la video. Sí. Permíteme mostrarte, annex.dev, si tienes más preguntas, ya sabes, solo ve aquí y puedes ver algunos de estos tutoriales o también hay un community Slack aquí. Si haces clic en este botón de Slack aquí arriba, permíteme mostrarte cómo se ve Slack. Aquí está. Los canales de soporte son probablemente los mejores. Entonces, ya sabes, hay muchas personas amigables y serviciales. El soporte es probablemente el canal más utilizado. Si tienes algún problema con el que te encuentres, hay muchas personas amigables y serviciales aquí. Algunos empleados de NX también están aquí, también. Entonces, si necesitas más ayuda, este es el lugar al que debes ir. De acuerdo, gracias.