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