Monorepos Rápidos de React con una Alta Calidad DX

Rate this content
Bookmark

Los monorepos han estado presentes durante algún tiempo, pero solo recientemente han ganado popularidad en la comunidad de JavaScript. La promesa de compartir fácilmente código, hacer cumplir mejores estándares organizativos, mayor movilidad del desarrollador debido a herramientas comunes y más, es muy atractiva. Sin embargo, si se aborda de manera ingenua, un monorepo rápidamente se convertirá en un gran desorden: tiempos de CI lentos que se disparan, dependencias enredadas entre proyectos, difícil de navegar y, en última instancia, frustrante. En esta charla, veremos las herramientas disponibles, cómo comenzar rápidamente un nuevo monorepo de React en particular y aprenderemos los ingredientes clave necesarios para construir un monorepo exitoso y duradero que se pueda escalar.

22 min
21 Jun, 2022

Video Summary and Transcription

Bienvenido a una charla sobre monorepos rápidos de React con una alta calidad DX. Los monorepos permiten la colaboración y el intercambio de código entre paquetes, proporcionando un entorno de desarrollo más organizado. Aprovechar el almacenamiento en caché y la distribución en CI puede mejorar la velocidad y eficiencia. NX proporciona una configuración de monorepo rica en funciones para React, mejorando la experiencia del desarrollador. Herramientas de monorepo como la extensión de consola NX y la visualización del gráfico del proyecto mejoran las capacidades y hacen cumplir la calidad del código.

Available in English

1. Introducción a los Monorepos de React

Short description:

Bienvenidos a mi charla sobre monorepos de React rápidos con una alta calidad de DX. Soy Joris Schumfler, Director de Experiencia de Desarrollador en Narwhal. Brindamos servicios de consultoría para empresas Fortune 500, especializándonos en monorepos. NX es un sistema de construcción inteligente, rápido y extensible que te ayuda a tener éxito a largo plazo. Es muy popular, superando el millón de dólares en diciembre y a punto de alcanzar los dos millones por semana en junio.

¡Hola y bienvenidos a mi charla sobre monorepos de React rápidos con una alta calidad de DX! Pero antes de continuar, permítanme presentarme. Mi nombre es Joris Schumfler, soy Director de Experiencia de Desarrollador aquí en Narwhal. También soy un Experto en Desarrollo Web certificado por Google. Soy instructor de ECHI y Embajador de Cybers.

Narwhal es la empresa detrás de NX y brindamos servicios de consultoría para empresas Fortune 500, pero no solo eso. Nuestro alcance abarca desde ayudar con el desarrollo de Angular y React, pero en particular, ayudamos con los monorepos, es decir, ayudamos a migrar a escenarios de monorepos, configurar nuevos monorepos, pero sobre todo, ayudamos a tener éxito con esos monorepos a largo plazo. También somos los creadores de la herramienta de código abierto NX. Y por si acaso te lo perdiste, recientemente también asumimos la responsabilidad de Leerna, que ahora se une a NX.

Entonces, ¿qué es NX? NX es un sistema de construcción inteligente, rápido y extensible que se puede utilizar para monorepos. Y hoy no voy a entrar específicamente en NX, pero lo estoy utilizando como un ejemplo de un conjunto de características como una herramienta de monorepo completamente funcional que puede ayudarte no solo a comenzar rápidamente, sino también a tener éxito a largo plazo. Ahora NX es muy popular. Hemos superado el millón de dólares en diciembre y probablemente alcanzaremos los dos millones por semana en junio. Es muy emocionante y muestra cuánto interés ha ganado el espacio de los monorepos recientemente.

2. Comprendiendo los Monorepos y Polyrepos

Short description:

Ahora, ¿qué son los monorepos? Recientemente, Rich Harris expresó su insatisfacción con el término monorepo, ya que implica un único repositorio para toda la organización. Sin embargo, en realidad, las grandes empresas a menudo tienen múltiples monorepos, divididos por departamento o dominio, junto con polyrepos. Estos repositorios pueden compartir componentes a través de registros internos, permitiendo que los polyrepos se beneficien de las bibliotecas construidas dentro de los monorepos. Por otro lado, un polyrepo es un escenario más tradicional con un único repositorio que contiene un proyecto.

Ahora, ¿qué son los monorepos? Rich Harris, hace un par de semanas, publicó un tweet con el que estoy totalmente de acuerdo, porque tengo la misma pregunta de las personas y tengo que responder y explicar una y otra vez. Básicamente, no estaba contento con el término monorepo. Y el problema es que monorepo implica, o lo que mucha gente piensa, es que necesitas tener un único repositorio para toda la organización. Ahora, es perfectamente comprensible por qué la gente piensa eso, pero en realidad, lo que vemos cuando trabajamos ahora, por ejemplo, con grandes empresas, es algo más como esto. Así que tienes grandes monorepos, un par de ellos dentro de tu empresa, tal vez divididos por departamento, organización o dominio, y luego también tienes los polyrepos existentes, o incluso nuevos polyrepos, que surgen dentro de esa organización. Entonces, si tienes una combinación de este tipo de paisaje y compartes cosas a través de registros, a través de registros internos, incluso los monorepos comparten algunas de las partes para el exterior. Porque si tienes algunos polyrepos que podrían beneficiarse de, digamos, la biblioteca de componentes que construyes dentro de un determinado monorepo, es posible que también quieras publicar eso en un registro, aparte de simplemente usarlo dentro de ese monorepo. Así que eso está perfectamente bien. Ahora, probablemente tener un término como repositorio multiproyecto versus repositorio de un solo proyecto sería más útil o más significativo, pero no voy a acuñar un nuevo término aquí. Así que cuando hablo de monorepos, lo que quiero decir básicamente es un único repositorio Git con dos o más proyectos distintos, y Polyrepo por otro lado es un escenario más clásico, que es bastante básico, que es como un único repositorio con un proyecto en él.

3. Explorando la Arquitectura de Monorepo

Short description:

Los monorepos adoptan diferentes formas. En algunos casos, se utilizan para la colocación de código y la reutilización de configuraciones de CI o utilidades comunes. Sin embargo, el verdadero valor de un monorepo radica en la colaboración y el intercambio de código entre paquetes. Al fusionar polyrepos separados en un monorepo, puedes dividir la base de código en subproyectos más pequeños, cada uno con bibliotecas específicas. Estas bibliotecas se pueden compartir entre dominios, lo que proporciona un entorno de desarrollo más organizado y permite APIs detalladas. También es posible crear bibliotecas de uso compartido dedicadas y bibliotecas de propósito general que se pueden publicar fuera del monorepo. Para garantizar un desarrollo rápido, es importante contar con herramientas que permitan construir solo lo que ha cambiado, como utilizar un gráfico de proyectos para determinar las dependencias y las aplicaciones afectadas.

Entonces, ¿cómo se ven los monorepos? Vienen en diferentes formas. En muchos casos, especialmente en el mundo del código abierto, lo que ves es simplemente un repositorio con la colocación de código. Tienes varios proyectos allí, que no necesariamente se relacionan entre sí o tienen relaciones entre ellos, por lo que la mayoría de las veces se trata de reutilizar configuraciones de CI o utilidades comunes para ser más rápidos en la publicación en NPM, cosas así.

Pero el verdadero valor que obtienes de un monorepo es si esos paquetes se relacionan entre sí en cierta medida. Comparten código y facilitan la colaboración dentro del monorepo. De hecho, un monorepo se trata de arquitecturar tu sistema. Muchas veces tienes escenarios como este. Tienes diferentes áreas de dominio dentro de tu organización y muy a menudo existen como polyrepos separados. Pero si los fusionas en un monorepo, el escenario podría verse así. Tienes estos dominios y a medida que evolucionas tu monorepo, lo divides en subproyectos más pequeños. Tienes una aplicación por cada dominio, que puedes implementar de forma independiente, y cada dominio tiene bibliotecas específicas que no se comparten con otros dominios o con otras partes del monorepo, sino que son específicas de ese dominio en particular.

La razón principal de tener esas bibliotecas es dividir la base de código, tener equipos más organizados y poder trabajar en proyectos individuales dentro de ese espacio de trabajo, básicamente dentro de ese dominio único, y también puedes tener APIs mucho más detalladas en ese caso, lo que te ayuda a crear un código más mantenible a largo plazo. Ahora, obviamente, obtienes más beneficios una vez que también comienzas a reutilizar cosas. En la parte inferior de esta imagen, por ejemplo, puedes ver esas bibliotecas que son utilizadas mucho por los dominios de nivel superior, y esas bibliotecas suelen ser utilidades de código, como bibliotecas de autenticación, bibliotecas de registro, tal vez para calcular fechas, o incluso algunas partes más específicas para tu dominio, para tu organización. Por ejemplo, podría ser una biblioteca de componentes de interfaz de usuario que se encuentra allí, que es utilizada por varias partes de los dominios para tener una apariencia y una sensación de interfaz de usuario uniforme. Así que, ya desde esa imagen, puedes ver que una idea errónea común queda demostrada como falsa, ¿verdad? Muchas personas piensan que monorepo es igual a monolito, lo cual es todo lo contrario, porque hemos visto que incluso tenemos diferentes aplicaciones por dominio dentro del monorepo. Por lo tanto, se pueden implementar de forma independiente. En lugar de crear un monolito, lo que haces es dividirlo, en este caso, aquí abajo, como puedes ver aquí, tenemos las bibliotecas de utilidades más generales que acabo de explicar, pero esas no son las únicas. Incluso puedes tener conexiones entre dominios. Y también en esos casos, es muy útil crear, por ejemplo, bibliotecas de uso compartido dedicadas, que expongan un objeto de datos común que puede ser utilizado por otros dominios e interfaces de API comunes, de modo que los dominios puedan comunicarse entre sí. Por ejemplo, el dominio de pago podría necesitar utilidades, ya sea utilidades de interfaz de usuario, pero también utilidades de comunicación para la parte de productos de los dominios de tu organización. Y finalmente, como mencioné antes, incluso puedes tener esos nodos finales muy generales, que son algunas bibliotecas de propósito muy general, como componentes de interfaz de usuario, que también puedes querer publicar fuera del monorepo, para que los polyrepos puedan consumirlos. Ahora, como puedes ver en mi título, la parte rápida es muy importante en el monorepo, porque si te acercas a ellos de manera ingenua, puede ser fácil comenzar, pero después de un año más o menos, las cosas pueden volverse muy, muy lentas rápidamente. Y si una solicitud de extracción en CI tarda más de una hora en construirse, eso dificulta el desarrollo de nuevas funciones y ralentiza a tus equipos. Básicamente, en lugar de fomentar la colaboración, comienzas a ser perjudicial. Definitivamente, necesitas tener herramientas que te permitan construir solo lo que ha cambiado, y la mayoría de las herramientas de monorepo tienen algo que se llama un gráfico de proyectos y lo que se puede hacer con un gráfico de proyectos es, por ejemplo, si una biblioteca como aquí en la imagen del medio cambia, esas herramientas pueden recorrer los gráficos de proyectos para comprender qué necesita ser construido o probado o analizado. En este caso, puedes ver que ya podemos eliminar muchas bibliotecas y aplicaciones que no necesitan ser modificadas. Obviamente, será mucho más rápido que también ejecutar pruebas para ellas.

4. Aprovechando el Caché y la Distribución en CI

Short description:

Puedes aprovechar esto para comprender qué necesita ser implementado nuevamente. El caché hace que el proceso sea más rápido al reutilizar los resultados de ejecuciones anteriores. NX Cloud permite el caché distribuido y la ejecución de tareas, mejorando la velocidad y eficiencia en CI. Al distribuir los cachés y las tareas de manera uniforme según los datos históricos, NX Cloud optimiza la utilización de recursos y reduce el tiempo de ejecución general.

Incluso puedes aprovechar esto, por ejemplo, para comprender qué necesita ser implementado nuevamente, como siempre tener la última versión en producción. En este caso, puedes ver que todas las aplicaciones en nuestros dominios se ven afectadas porque es una biblioteca muy central en este caso que ha cambiado. Y probablemente querríamos implementar todas esas aplicaciones también.

Ahora, afectado es solo una parte. El caché es lo que hace que sea aún más rápido. Por ejemplo, tomemos ese mismo escenario donde. Cambiamos esas bibliotecas y todas se ejecutan en CI y una de las bibliotecas, como en la esquina superior izquierda, falla la prueba. Entonces el desarrollador las revisa, las descarga, corrige la prueba, las vuelve a enviar. Ahora no tenemos que ejecutar todas nuevamente porque todas las demás partes no se ven afectadas por el cambio que acaba de hacerse. Todavía se ven afectadas en comparación con la rama principal como master o main. Sin embargo, solo necesitamos ejecutar las pruebas nuevamente o calcular nuevamente para la biblioteca y la aplicación en la esquina superior izquierda. Porque todos los demás resultados se pueden obtener del caché. Obviamente, obtienes mucha más velocidad.

Ahora la distribución es realmente la clave aquí porque actualmente el caché, por ejemplo, en NX específicamente, de forma predeterminada es local. Es local para la estación de trabajo de cada desarrollador, lo que significa que el desarrollo local se vuelve más rápido y se acelera, pero no puedes aprovecharlo realmente, especialmente en CI. Y ahí es donde vemos que mucha gente usa el caché porque quieres asegurarte de que las solicitudes de extracción sean rápidas para fusionarse. Y para poder tener un caché distribuido, necesitas un contraparte central en el servidor, en el caso de NX es NXCloud, que te permite distribuir ese caché entre los miembros del equipo y también en CI. Y NXCloud va un paso más allá. No solo distribuye el caché real, sino que también distribuye la ejecución de tareas, lo que lo hace aún más rápido. Normalmente, en CI, lo que haces es obtener ese gráfico de proyectos que se vio afectado por el cambio. Y luego tienes un conjunto de agentes porque lo que quieres hacer es paralelizar tanto trabajo como sea posible. Y así puedes dividirlo en lotes iguales. Eso es lo que suele suceder. Ese es el enfoque más ingenuo, simplemente dividirlos en lotes iguales y distribuirlos entre los agentes. Sin embargo, lo que podría suceder es que algunos agentes sean muy rápidos porque tienen tareas que se completan en unos segundos, mientras que otros agentes tardan minutos. Y así, toda la ejecución de CI tiene que esperar hasta que todos los agentes terminen. Por lo tanto, la utilización de los agentes no es óptima. Y también el tiempo real no es óptimo al final. No es tan rápido como se esperaría. Ahora, NXCloud, por ejemplo, distribuye los cachés o distribuye no solo los cachés, sino también las tareas de manera uniforme según los datos históricos.

5. Mejorando la Experiencia del Desarrollador con NX

Short description:

NX proporciona una configuración de monorepo rápida y rica en funciones para React. Ofrece una configuración central para escenarios de migración y plantillas preconfiguradas para nuevos monorepos. La configuración central aprovecha el programador de tareas rápidas, el caché y la ejecución de tareas distribuidas con NX Cloud. Configurar NX es fácil y se puede integrar con monorepos existentes o utilizarlo para nuevos proyectos. NX también mejora la experiencia del desarrollador con una salida hermosa que se enfoca en lo más importante y reduce la carga cognitiva.

Y así sabe, según el gráfico, qué procesos se pueden construir en paralelo, donde básicamente pueden asignar una sola tarea a un agente porque es una tarea de larga duración y cuál debe ejecutarse en serie. Y al final, la parte de DX, aquí es donde se recopilan y envían todos los registros y artefactos al nodo principal real y se agrupan. Y desde la perspectiva de un desarrollador, si ocurre un error o desea ver la ejecución real, simplemente puede ir a los registros y los verá de la misma manera que si se hubieran ejecutado en una sola máquina.

Y es aún mejor porque todas esas tareas ahora están distribuidas en los agentes. Aquí, puedes ver una captura de pantalla de NX cloud que muestra la utilización de los agentes y cómo se equilibran también en función de los datos previos que NX cloud ha obtenido y, por lo tanto, sabe cómo paralelizar mejor esas tareas. Y obtienes incluso una visualización agradable. Entonces, cada vez que se ejecuta una PR, puedes entender en tiempo real cuántos agentes están ejecutándose actualmente, qué tareas se están ejecutando en qué agente, lo cual es particularmente importante para fines de depuración.

Ahora, esto fue un poco rápido y ya un poco entrelazado con la parte de DX, como acabamos de ver, como la visualización, por ejemplo, que te ayuda desde una perspectiva de experiencia de desarrollador a depurar cosas. Pero DX es muy importante en React, más en el escenario de monorepo en general, porque no hay nada como tener una configuración de monorepo rápida, súper completa de funciones, pero es muy difícil de usar o configurar desde una perspectiva de desarrollador. Y en NX específicamente, la parte importante es la parte de experiencia de desarrollador. Y, en primer lugar, las cosas deben adoptarse incrementalmente, ¿verdad? Por lo tanto, NX se puede configurar de dos formas principales diferentes. Puedes comenzar con una configuración central, lo que significa que no usas ningún complemento que venga con NX, solo instalas NX y lo usas en tu monorepo existente.

Y para escenarios de migración, esto es ideal porque aún puedes usar la misma infraestructura que tenías antes, y NX simplemente hará que las tareas se ejecuten mucho más rápido. Lo que aprovechas es el programador de tareas rápidas, el caché y también la ejecución de tareas distribuidas si usas NX cloud, como acabas de ver. El otro enfoque es que si comienzas de nuevo, puedes beneficiarte de configurar NX con algunas cosas preconfiguradas. Por ejemplo, puedes decir: `Sé que estoy usando una configuración de monorepo de react porque react es mi enfoque principal`. Entonces, ya puedes usar algunas plantillas preconfiguradas que vienen con NX. Y NX se asegurará de que tengas la configuración de Jest, ESLint, Prettier, configuración de Cypress lista para ti. Por lo que no tienes que preocuparte por muchas de esas cosas. Por lo general, esa es la mejor opción si estás comenzando un nuevo monorepo en este momento.

Por lo tanto, para la configuración central, es muy fácil de ajustar. Básicamente, solo ejecutas el comando npx add NX to monorepo, que lo agregaría a cualquier espacio de trabajo de npm, yarn, pnpm y simplemente lo haría mucho más rápido. Curiosamente, como mencioné al principio, asumimos el control de Seo Chip para Lerna, y ahora podemos hacer cosas muy interesantes, especialmente para tus espacios de trabajo de Lerna. Por ejemplo, en este momento, si estás usando Lerna 5.1 o superior, solo tienes que instalar NX y establecer use NX en true en tu archivo Lerna JSON, y automáticamente delegará la programación de tareas a NX, lo que hará que Lerna sea súper rápido sin que tengas que cambiar nada más, lo cual es muy importante, creo, desde una perspectiva de economía de desarrollador.

Otra cosa es la salida hermosa. Ahora, esto puede no parecer tan importante inicialmente, pero si piensas en cuántas veces miras las salidas de la terminal como desarrollador, y para reducir la carga cognitiva, NX realmente solo muestra lo más importante en este momento. Por ejemplo, no muestra la ejecución de tareas dependientes como en esta animación aquí, sino solo lo que se ejecuta, a menos que, por supuesto, ocurra algún error. Eso se resaltaría, obviamente, en grande y en rojo, e incluso si vuelves a ejecutar la tarea y se almacenan en caché, la salida es exactamente la misma. Por lo tanto, básicamente tienes una carga cognitiva mucho menor cuando analizas esos registros porque solo ves lo que necesitas en este momento. También la integración de ID.

6. Explorando las Capacidades de los Monorepos

Short description:

Esta parte explora las capacidades de las herramientas de monorepo, como la extensión de consola NX para Visual Studio Code. También se discute la visualización de los gráficos de proyectos y los beneficios de los co-generadores para la integración de desarrolladores junior. Además, se destaca la prevención de dependencias enredadas a través de un sistema de etiquetado.

Esto es especialmente interesante para los recién llegados, pero también si quieres explorar simplemente las capacidades que tienes, ¿verdad? Por ejemplo, para Visual Studio Code, pero también hay extensiones de la comunidad para WebZone, por ejemplo, tenemos la extensión de consola NX, que te permite navegar dentro de un espacio de trabajo NX y en el futuro incluso un espacio de trabajo de Lerna, lo que te permite explorar los comandos que puedes ejecutar, las cosas que puedes generar en ese espacio de trabajo visualmente desde Visual Studio Code.

Otra parte, la parte visual, también es muy importante al explorar el espacio de trabajo. Entonces, muchas de estas herramientas de monorepo tienen un llamado gráfico de proyecto debajo. Ahora, en NX hemos ido un paso más allá y lo hemos visualizado como una aplicación web dinámica que puedes iniciar directamente desde tu CLI. Y aquí puedes ver cómo puedes, por ejemplo, tomar dos nodos y básicamente hacer que NX visualice el camino más corto entre esos nodos, así como todos los caminos potenciales. Y puedes imaginar cómo eso puede ayudar a comprender por qué algunos nodos se conectan entre sí, como por qué existe la conexión, pero también, por ejemplo, para depurar dependencias circulares.

Y finalmente, una parte muy importante no es solo comenzar rápidamente como hemos visto en términos de ser rápido, sino también el soporte continuo a medida que tu monorepo crece. Los co-generadores son una cosa que puede ayudarte con eso, que viene con NX, lo que significa, por ejemplo, si tienes co-generadores para facilitar la integración de desarrolladores junior, ya tienes algunos co-generadores en su lugar para que todas las bibliotecas y aplicaciones se generen de manera uniforme como se esperaría. Entonces, no tienes que copiar y pegar, lo cual es propenso a errores, por supuesto, las bibliotecas existentes eliminan el código existente y luego continúan trabajando en eso. Pero incluso puedes no solo usar los generadores proporcionados por NX, sino adaptarlos realmente a tus propias necesidades. Puedes personalizarlos para que solo se genere lo que necesitas en tu espacio de trabajo actual. Fácilmente, eso también se puede activar desde Visual Studio Code. Y aquí, por ejemplo, puedes ver en este ejemplo de animación cómo configurar ese entorno de ejecución de tareas distribuidas para CI. Entonces, puedes generar fácilmente esa configuración de CI, que es muy útil. Y solo son un par de líneas de código, si lo miras al final. Entonces, este es un ejemplo de lo poderosos que pueden ser esos generadores sin que tengas que escribir largos documentos explicando cómo configurar esas cosas. De manera similar, por ejemplo, si quieres configurar una modificación de Webpack para React, NX ya viene con un complemento que puedes usar para configurar las aplicaciones principales y remotas. Y luego puedes usar eso para construir tus cosas existentes y continuar desarrollando sobre esos generadores.

Finalmente, también se previene las dependencias enredadas. Y esto es algo que la gente subestima mucho cuando comienza en monorepos. Porque comienzan muy emocionados al principio. Pero luego, si estás en medio de un año donde tienes varios equipos trabajando en un monorepo, las cosas pueden volverse desordenadas muy, muy rápido. Entonces, las personas importan de bibliotecas que no deberían importar, y tal vez incluso por accidente, porque vieron alguna biblioteca de utilidades genial y no se suponía que la usaran. Rápidamente, tu código puede volverse inmantenible. En NX, por ejemplo, como puedes ver aquí, puedes usar esas bibliotecas como dominios, ¿verdad? Donde puedes exponer claramente una API pública, para que otras personas de un dominio diferente puedan aprovechar esas funciones en su propio dominio. Ahora, ¿cómo puedes evitar que alguien importe una biblioteca diferente? En teoría, puedes hacerlo porque vives en el mismo monorepo. Ahora, en NX tenemos un sistema de etiquetado. Estas son simplemente cadenas. Entonces, puedes decir, por ejemplo, tengo una columna de alcance, algún nombre, que por ejemplo podría ser los dominios, y darle esas etiquetas a todas las aplicaciones y bibliotecas en un cierto dominio. Puedes agregar eso en tu configuración y todas esas bibliotecas lo recibirían.

7. Aplicación de Dependencias y Calidad del Código

Short description:

Puedes usar etiquetas específicas para marcar las API que pueden ser consumidas desde fuera del dominio. Las reglas de ESLint pueden definir etiquetas de origen para aplicar dependencias dentro de dominios específicos. Ejecutar estas comprobaciones en CI y editores ayuda a mantener la calidad del código.

Y luego también le das a esa API, por ejemplo, una etiqueta específica para marcarla como algo que puede ser consumido desde fuera del dominio. Y luego viene lo siguiente con una regla específica de ESLint. Entonces, en esta regla de ESLint aquí, por ejemplo, puedes ver cómo definimos una etiqueta de origen y decimos, OK, algo que se llama scope checkout, que es nuestro dominio de pago específico, solo puede depender de otras aplicaciones y bibliotecas que también vivan en ese scope checkout para que también tengan esa etiqueta o que tengan un API de scope. Porque, como, si hay un API de scope, hay algo que se puede usar explícitamente. Así que está bien. Y estas comprobaciones se pueden ejecutar en CI. Se ejecutan en tu editor. Así que ves inmediatamente si importas algo incorrecto y, por lo tanto, son muy, muy poderosas para mantener tu código mantenible. Y finalmente, migraciones automatizadas. Algo similar que mucha gente subestima, pero creo que escenarios como estos son muy comunes de usar. Entonces, los desarrolladores pueden plantear en la reunión que parece que necesitamos actualizar Webpack. Nuestra herramienta está desactualizada. Webpack ha estado funcionando durante un par de años. Definitivamente deberíamos actualizar. Además, React 18 ha salido. Así que tal vez deberíamos echarle un vistazo. Y lo que dice un gerente de producto, obviamente, es como, OK, entiendo que esto es importante. ¿Qué tan importante es? ¿Bloquea el envío de funciones? Y la mayoría de las veces no lo hace, ¿verdad? Es solo una tarea de mantenimiento que debe hacerse, ¿verdad? Pero obviamente, si esto lleva semanas y semanas, es muy difícil de llevar a cabo. Y así, la mayoría de las veces lo que sucede es como, sí, claro, los gerentes de producto no entienden. Pero, sí, hagámoslo para el tercer trimestre. Podemos reservar algo de tiempo, ¿verdad? Todos sabemos lo que sucede cuando llega el tercer trimestre. Toneladas de nuevas funciones, plazos muy urgentes. ¿Qué sucede con la herramienta? Simplemente se retrasa. Y así, una cosa que hacemos con NX y que implementamos con mucho éxito también en grandes empresas, es la migración de NX. Y así, lo que sucede aquí es que NX tiene una función incorporada que le permite definir scripts de migración que no solo migran tu configuración, sino también tu código fuente de una versión a la siguiente. Y así, si estás dentro de un espacio de trabajo NX existente y usas complementos de NX, NX sabe qué funciones estás usando, ¿verdad? Y así, cada vez que actualizas, simplemente ejecutas NX migrate, que analizará tu espacio de trabajo, actualizará tu package JSON, y luego generará un conjunto de scripts de migración que luego puedes inspeccionar y ejecutar en tu espacio de trabajo. Y así, esto transformará cosas como, por ejemplo, integraciones de Jest, actualizará tu Cypress a la última versión, actualizará React 18, cualquier versión de React a la que estés actualizando, y se asegurará de que el código siga siendo consistente ajustando también el código fuente potencial. Así que esta es una característica muy poderosa, algo que se subestima rápidamente. En general, me gustaría concluir, diciendo que una buena herramienta debería estar ahí para permitirte tomar las decisiones correctas, pero no solo ayudarte a comenzar rápidamente, lo cual es definitivamente importante para la adopción incremental, como hemos visto, sino que también debería ayudarte durante todo el ciclo de desarrollo. Y así, con NX, obtienes funciones que se pueden adoptar de forma incremental. Puedes personalizarlo según tus propios requisitos proporcionando, por ejemplo, generadores personalizados y especificando el diseño como deseas tenerlo. Y luego viene con todas esas características únicas, como la exploración visual de gráficos, cosas como las que hemos visto con las etiquetas de las reglas de lint de los clientes que te ayudan a mantener realmente tu espacio de trabajo y monorepo saludables a largo plazo. Definitivamente echa un vistazo a monorepo.tools y si quieres ponerte en contacto conmigo con preguntas, lo que sea, ponte en contacto con nuestra cuenta de Twitter de NX DevTools, a devrel en novel.io o en mi propia cuenta de Twitter, yuristr. Muchas gracias por ver. Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.
GraphQL Galaxy 2022GraphQL Galaxy 2022
31 min
Your GraphQL Groove
Building with GraphQL for the first time can be anywhere between daunting and easy-peasy. Understanding which features to look for in your client-side and server-side tooling and getting into the right habits (and ridding yourself of old habits) is the key to succeed with a team of any size in GraphQL.

This talk gives an overview of common struggles I've seen numerous teams have when building with GraphQL, how they got around common sources of frustration, and the mindset they eventually adopted, and lessons learned, so you can confidently stick with and adopt GraphQL!
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!

Workshops on related topic

React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Node Congress 2023Node Congress 2023
160 min
Node Monorepos with Nx
WorkshopFree
Multiple apis and multiple teams all in the same repository can cause a lot of headaches, but Nx has you covered. Learn to share code, maintain configuration files and coordinate changes in a monorepo that can scale as large as your organisation does. Nx allows you to bring structure to a repository with hundreds of contributors and eliminates the CI slowdowns that typically occur as the codebase grows.
Table of contents:- Lab 1 - Generate an empty workspace- Lab 2 - Generate a node api- Lab 3 - Executors- Lab 4 - Migrations- Lab 5 - Generate an auth library- Lab 6 - Generate a database library- Lab 7 - Add a node cli- Lab 8 - Module boundaries- Lab 9 - Plugins and Generators - Intro- Lab 10 - Plugins and Generators - Modifying files- Lab 11 - Setting up CI- Lab 12 - Distributed caching
React Advanced Conference 2021React Advanced Conference 2021
168 min
How to create editor experiences your team will love
Workshop
Content is a crucial part of what you build on the web. Modern web technologies brings a lot to the developer experience in terms of building content-driven sites, but how can we improve things for editors and content creators? In this workshop you’ll learn how use Sanity.io to approach structured content modeling, and how to build, iterate, and configure your own CMS to unify data models with efficient and delightful editor experiences. It’s intended for web developers who want to deliver better content experiences for their content teams and clients.