Historia de Dos Repositorios

Era el mejor de los tiempos, era el peor de los tiempos. Alrededor de la última década, JavaScript comenzó a volverse muy popular, a mediados de 2010. Y la introducción de Node fue una de las cosas, y frameworks avanzados como Angular y React fueron introducidos, y se volvió realmente popular.

En 2015, JavaScript realmente despertó de un profundo sueño de unos años y tuvo muchas características nuevas. Esto se conoció como ECMAScript 6, o como nos gusta llamarlo, ES6. Pero también hubo algunos problemas, porque los motores que ejecutaban el lenguaje, es decir, Node, y esto es un navegador diferente, y especialmente un navegador que ya no está con nosotros, no sabían cómo manejar esas cosas.

Cosas como Operadores de propagación, Función de error, Const y Let eran extremadamente útiles al escribir código JavaScript, pero simplemente aún no eran compatibles. Y nosotros, los desarrolladores, queremos esas características ahora mismo. En 2014, un joven llamado Sebastian MacKenzie comenzó un proyecto para aprender más sobre el funcionamiento de JavaScript y estaba tratando de convertir el código de ES6, para que pudiera ser utilizado en el navegador que admitía ES5. Así que Sebastian creó un repositorio y construyó el núcleo de un proyecto, pero como había tantas características para ES6 y seguían llegando más todo el tiempo, decidieron construirlo de forma extensible y utilizando complementos.

Así que abrieron un repositorio para cada uno de los complementos para que pudieran ser instalados por separado. Y el proyecto creció y creció y creció porque había tantos complementos. Así que decidieron juntar todos los repositorios de los diferentes complementos en un solo complemento. Y por cierto, al mismo tiempo, también cambiaron el nombre del proyecto. Ya no lo llamaban 6to5 como antes, y cambiaron el nombre a Babyl. Así que pusieron todos sus complementos en un repositorio que podía publicar muchos paquetes. Y esta decisión fue muy, muy controvertida en ese momento, no estaba muy clara en absoluto. Y fue tan controvertida que tuvieron que escribir en su repositorio de GitHub una explicación de por qué lo estaban haciendo. Y también construyeron algunas utilidades para ayudarles a gestionar los diferentes paquetes. Más tarde, extrajeron todas estas utilidades en un repositorio separado, nuevamente, otro repositorio, y lo llamaron Lerna. Y en ese entonces y durante mucho tiempo, tal vez incluso hasta hoy, Lerna era sinónimo de usar Monorepos. Pero creo que la forma en que usamos JavaScript y Monorepos en 2015 no es realmente lo que necesitamos hacer hoy en 2023 y la forma de manejar un JavaScript moderno.

El problema es que a veces pasamos por alto eso y llegamos al punto en que simplemente decimos la palabra mágica Monorepos y asumimos que todos están hablando de lo mismo. Pero la realidad es que Monorepos es algo grande y todos significan algo completamente diferente. Solo para darte un ejemplo. Si miramos dos herramientas populares, Yarn y NX, usan el mismo término pero para cosas opuestas. En Yarn, un workspace es un solo paquete. En NX, cuando dicen workspace se refieren a todo el Monorepo. Así que soy Talib Barak y he estado jugando con Monorepos desde 2017. Así que eso es bastante tiempo.

Y no voy a hablar de esa herramienta o esa herramienta, Yarn o NX o TurboRepo. Quiero aprovechar esta oportunidad y estos pocos minutos para explicar cuáles son las decisiones, cuáles son las estrategias que debemos tomar cuando nos mudamos o tenemos un Monorepo. Porque estas decisiones, que a veces tomamos sin preocuparnos realmente por ellas, las tomamos como ideas implícitas, en realidad tienen un impacto en todo nuestro proceso de desarrollo. Impactarán en la calidad de nuestro producto, en la velocidad de desarrollo, en la formación que debemos brindar al equipo, y así sucesivamente.

No hay una respuesta correcta o incorrecta aquí de la que vaya a hablar y decir, mira, esta es una forma de hacerlo, pero más bien, cuáles son las consideraciones, en qué cosas debes pensar. Entonces, si volvemos atrás, ¿qué es un Monorepo? Un Monorepo es un único repositorio que contiene múltiples artefactos, cosas que deseas compartir, cosas que deseas publicar. Esto puede ser un paquete, un servicio backend, una aplicación frontend, y así sucesivamente.

Y la primera pregunta importante que debes hacerte cuando te pasas a un Monorepo es qué quiero incluir en mi Monorepo. Esto puede ser muchas cosas diferentes. Pueden ser las diferentes herramientas que estamos utilizando. Puede ser una aplicación frontend, microservicios, paquetes, servidores backend, y así sucesivamente. Esta es como la decisión de punto cero. ¿Qué pongo? Y no significa que tengas que poner todo el código de la empresa dentro de un solo Monorepo. Definitivamente puede ser solo una parte del código que tienes.

La otra decisión es si realmente debería optar por un Monorepo. Hay muchos artículos, deberías buscar si debería usar un Monorepo, y luego hay una respuesta, no deberías usar un Monorepo, y así sucesivamente. Entonces, en tercer lugar, porque hay diferentes consideraciones y diferentes cosas en las que debes pensar cuando tienes un Monorepo. Pero digamos que decidiste que sí, queremos ir con el Monorepo. Tu repositorio incluirá múltiples artefactos, y en el mundo de JavaScript y Node.js, esto significa que tendrá múltiples archivos package.json. Cada archivo package.json está relacionado con un artefacto que deseas publicar.

Y lo primero que tenemos dentro de nuestro archivo package.json es qué artefactos, qué dependencias y qué dependencias necesita este artefacto para funcionar. Y esto nos lleva a nuestra primera decisión, que es la instalación. Así es como se ven nuestros paquetes. De acuerdo. En cada archivo package.json, tenemos un conjunto de dependencias. Y cómo vamos a instalar. Entonces, si seguimos el mismo enfoque que usamos en un repositorio políglota cuando teníamos múltiples repositorios, significa que bajo cada paquete tendré un módulo de nodo que... No puedo hacer eso. Que tendrá todos los paquetes que necesita. Pero como sabemos que node_modules es algo realmente grande, y no queremos replicarlo múltiples veces para cada una de las dependencias, en realidad tenemos otro enfoque que podemos usar. Y este enfoque es agrupar los paquetes. En lugar de instalar cada paquete en su propio espacio de trabajo, podemos mover todo a la raíz de nuestro proyecto, de nuestro repositorio, e instalarlos una vez allí. Y la razón por la que esto funcionará, conocemos el algoritmo de búsqueda de node.

Significa que comenzará desde abajo, intentará encontrar el paquete que hicimos, como bar aquí. Si no lo encuentra, subirá un nivel. Luego no lo encontrará y subirá un nivel más. Y luego, en la raíz del proyecto, lo encontrará. Así que eso es lo primero.

Hay un buen detalle que suele suceder. Esto es que cuando estamos usando este enfoque de alojamiento, podemos olvidar en uno de los paquetes poner una dependencia. Y luego, cuando lo implementamos en producción, donde no tenemos el monorepo, en realidad tenemos cada paquete por separado, de repente descubriremos que no podemos encontrar el módulo requerido. Esto se puede solucionar, y hay complementos que lo hacen. Esto es todo bueno para las dependencias externas. Por lo general, configuramos un monorepo porque tenemos artefactos que están conectados. Y esto nos permite, por ejemplo, compartir código. Entonces podemos tener un paquete que múltiples artefactos pueden compartir. Múltiples otros paquetes dependen de él. Y, como en este ejemplo, donde tenemos un servicio u otro paquete que depende del paquete. Y esto nos lleva a nuestra segunda estrategia, que es cómo enlazamos realmente los paquetes que existen en nuestro monorepo? En nuestro package json, no solo tenemos los externos, sino también los locales. Y aunque el problema parece muy similar al problema anterior, podemos instalarlo localmente o instalarlo globalmente, en realidad es bastante diferente. Porque el código de estos paquetes está dentro de nuestro monorepos. Entonces, en lugar de simplemente señalar algo externo, en realidad vamos a señalar un paquete que es interno.

Algunos de ustedes dirían, mira, resolvimos esto para los paquetes externos, hagamos lo mismo para los paquetes internos. Probémoslos, construyámoslos, versionémoslos, publiquémoslos en algún registro de artefactos que tengamos, y luego instalémoslos desde el registro de artefactos. Y esta es en realidad una opción válida, y sé que hay proyectos que la están implementando. No puedes instalar nada localmente, debes publicarlo en un registro de paquetes, incluso si es privado, y luego, para usarlo, debes instalarlo desde allí. Pero también hay otra solución que podemos implementar aquí porque esto es nuestro local, y porque en algunos casos queremos hacer cambios en nuestro paquete, y tal vez nuestro cambio no se limite a un solo paquete, sino que queremos hacer un cambio que abarque múltiples artefactos. Entonces, en este caso, esto se resolvió por YARN, incluso con la versión YARN 1. Especificarías que necesitas un paquete de otro paquete, y luego no instalará realmente los modules de nodo, sino que simplemente creará un enlace simbólico, simplemente creará una referencia desde los modules de nodo actuales hacia el otro paquete. Entonces, sí, fue la era de la insensatez, fue la época de la creencia, y con todas las nuevas herramientas que se introdujeron, en realidad se volvió más complejo. Ya no podemos simplemente señalar el código fuente y decir, esto es lo que debe ejecutarse, porque teníamos cosas como queríamos tipos, así que teníamos TypeScript. Queríamos características más nuevas, así que teníamos Babel del que hablamos. Queríamos tener paquetes más grandes.

Esto es principalmente para aplicaciones web, por lo que introdujimos herramientas como Webpack, pero al mismo tiempo queríamos asegurarnos de que se pudiera cargar automáticamente, por lo que queríamos análisis estático de módulos y todo tipo de cosas.

Entonces ahora tenemos un problema. Estamos apuntando a nuestro código fuente, pero nuestro código fuente no puede ejecutarse tal como está. Necesitamos algún tipo de traducción o proceso de construcción que lo haga disponible. Y aquí es donde introdujimos otro enfoque, que en lugar de apuntar al artefacto de construcción, en lugar de apuntar, lo siento, al código sin procesar, a la fuente, en realidad deberías apuntar al artefacto de construcción. Y este es otro enfoque que resuelve el mismo problema.

La tercera estrategia de la que quiero hablar es sobre el proceso de desarrollo. Ahora que el proceso de desarrollo es más complejo y necesitamos realizar un proceso de construcción, y definitivamente queremos probar nuestro código y queremos ejecutar algunas pruebas de linting, etc. ¿Cómo lo definimos? Porque aquí tenemos dos enfoques que se repetirán de alguna manera a través de otras cosas. ¿Debería hacerlo a nivel de paquete, a nivel de artefacto? Cada paquete realizará sus propias pruebas como si se ejecutara en el PolyRepo. Y simplemente ejecutaremos el script para cada paquete por separado. Y esto es exactamente lo que hacen herramientas como Yarn Workspace y NPM Workspace. Simplemente asumen que cada uno es independiente.

También podemos tener una especie de cada uno. El problema aquí es que tenemos cada configuración separada en cada uno de los paquetes. Y si necesitamos hacer algún cambio o si queremos que algo sea unificado en todo nuestro proyecto, en realidad necesitamos ir a cada uno de los paquetes y solucionarlo.

Entonces, otro enfoque es, bueno, vamos a centralizar la configuración, pero aún así ejecutar cada prueba en cada uno de los proyectos. Y existen herramientas como Jest, si quieres ejecutar pruebas, que te permiten hacer eso. Definirás todos los proyectos en una configuración y luego podrás compartir mucha configuración. Pero la ejecución se realiza en un proyecto o paquete por separado. ¿Trabajamos de manera centralizada o de manera distribuida? ¿Significa esto que todo lo que hacemos es en todos los paquetes o se distribuye entre ellos?

Lo siguiente es sobre la construcción. ¿De acuerdo? Entonces dijimos que tenemos que pasar por un proceso de construcción y así es como trabajamos en ello. Puedes simplemente ejecutar un script que haga lo que quieras o NX tiene alguna idea que ahora están retrocediendo que es tener un constructor que sepa cómo construir tus constructores. NX comenzó en realidad desde el proyecto Angular CLI desde entonces se desvió bastante pero aquí es donde se les ocurrió la idea de que necesitamos un ejecutor y como dije, ahora están retrocediendo. Aquí tengo la estructura lógica del monorepo. No es la estructura física de los archivos, sino la lógica y la forma en que está estructurada es en forma de un DAG que es acíclico dirigido con más como un pensamiento esperanzador. Significa que tienes algunas rutas, dependiendo de cómo quieras verlo. Estos son paquetes que no dependen de todo y luego, encima de eso, tienes paquetes y paquetes que dependen cada vez más de él. Y para ejecutar la construcción, si quieres construir todo es hacer lo que se llama una clasificación topológica. Así que eso significa que comienzas desde el paquete que no tiene dependencias y luego todos los paquetes que dependen de él y luego los paquetes que dependen de él y así sucesivamente. Y luego obtienes una forma de ejecutar todas las construcciones de una manera que tenga sentido, que no te perderás, no obtendrás versiones antiguas.

Y una construcción ingenua aquí diría, bueno, tengo mi clasificación topológica, puedo simplemente ir uno por uno y construir todo en el camino, solo lo que esté allí. Otro enfoque más avanzado sobre eso, que por supuesto llevará mucho tiempo y es posible que no desees hacer todo eso. Otro enfoque es decir, mira, estoy trabajando con control de origen, digamos con Git. Sé qué se cambió y luego puedo comenzar con el paquete que se cambió. Entonces, todo lo que está más abajo en la clasificación topológica pero no se cambió, no necesito reconstruirlo, ya tengo su construcción. Y luego puedes hacer todos los cambios. Otra optimización que puedes hacer sobre eso es usar la caché. Entonces, no solo pasar por los paquetes que se cambiaron, también puedes omitir los paquetes que no se cambiaron. Entonces construirás el paquete cinco, construirás el paquete cuatro. El paquete uno tal vez solo dependa del cinco. Entonces puedes almacenarlo en caché, o incluso en el cuatro pero no se cambió. Entonces puedes usar una construcción en caché y luego puedes continuar.

Y esto es similar a lo que NX está haciendo como parte de su optimización. Esto es lo que debemos pensar cuando consideramos nuestro proceso de construcción.

La última estrategia, estrategia número cinco, se trata del lanzamiento. ¿Cómo publico mi código al mundo? ¿Y cómo versiono? Esta es una decisión realmente crítica, probablemente la más crítica. Si tengo todos estos paquetes, ¿cómo gestiono la versión en ellos? Hay dos enfoques principales. Uno es unificado. Incluso si hay paquetes que no han cambiado, cuando publico un nuevo lanzamiento, o una nueva aplicación, o nuevos microservicios, publicaré todo bajo el mismo lanzamiento. Como ejemplo, Angular está haciendo exactamente eso. Cada vez que lanzan, lanzan todos los paquetes. Storybook también está haciendo algo similar. Todos los paquetes en el monorepo tienen solo una versión, independientemente de lo que haya cambiado. Otro enfoque es distribuido, donde todo será independiente. Entonces, este paquete será la versión 1.1, y este es el 3.2, y solo lanzaré la versión a la que realmente le hice cambios. Y, por supuesto, luego tendré que asegurarme de que los otros paquetes o aplicaciones que dependen de él sean compatibles hacia atrás y aún puedan funcionar con la nueva versión. Y si estoy actualizando una dependencia, en realidad es un cambio en mi paquete. Fue una temporada de luz, fue una temporada de oscuridad.

Entonces, si tratamos de resumir todo, lo primero que debes hacer es, sí, cuál es el alcance de mi monorepo, qué necesito poner dentro, y luego debes pasar por las cinco etapas de la estrategia. Instalar, vincular, desarrollar, estrategia de construcción y estrategia de lanzamiento. Pero, de hecho, sugeriría que este no es el orden en el que debes pensar. De hecho, debes pensarlo en orden inverso. Comienza desde el lanzamiento. ¿Cuál es tu objetivo? ¿Cómo quieres lanzar? Eso derivará cuál es tu estrategia de construcción, probablemente derivará tu estrategia de desarrollo, porque si estás lanzando por separado, no necesitas probar todo, y eso determinará cuál es la estrategia de vinculación e instalación. Y solo después de haber seguido este enfoque, y saber cuál es tu estrategia y qué quieres aplicar en tu monorepo, entonces debes seleccionar las herramientas, Learn.io, Linux, PNPM workspaces, TurboRepo, y así sucesivamente, las que realmente se ajusten a tu estrategia. Sí, así que hay algo de esperanza y algo de luz al final del invierno, y muchas gracias por escuchar y aquí es donde puedes encontrarme. Muchas gracias.