Proyecto Ledger Live Monorepo: Parte 2 - Las herramientas (Hazlo brillar) | Libro mayor

Proyecto Ledger Live Monorepo: Parte 2 – Las herramientas (Hazlo brillar) | Libro mayor

Nodo de origen: 2985172

Segunda entrada de la serie de publicaciones del blog “Proyecto Ledger Live Monorepo”, donde un desarrollador de Ledger nos cuenta la historia de la enorme migración del código base de Ledger Live a un repositorio mono. Si te perdiste la parte 1, échale un vistazo aquí:

Después de establecer que una arquitectura monorepo era una solución viable, comenzamos a buscar las herramientas disponibles para implementar nuestro plan.

Manejo de múltiples proyectos

En el equipo de Ledger Live navegamos en el ecosistema JavaScript y, afortunadamente para nosotros, ya conocíamos varias formas de manejar múltiples proyectos con nuestro administrador de paquetes. Algunas de esas posibles soluciones incluyen:

  • NPM (tiene soporte para espacios de trabajo pero mejores alternativas),
  • Hilado 1 (volviéndose alternativas demasiado antiguas, mejores y más eficientes),
  • Hilo ≥ 2 (idea interesante, pero plug and play no es compatible con todas partes, especialmente con React Native),
  • PNPM (enlaces simbólicos, creados teniendo en cuenta los espacios de trabajo, eficientes en disco).

Después de ver todo esto, decidimos ir con PNPM para:

  • la eficiencia del disco (utiliza un virtual tienda y enlaces simbólicos, por lo que los paquetes se descargan solo una vez y luego se vinculan simbólicamente a sus node_modules desde la tienda virtual),
  • la velocidad (dado que los paquetes se almacenan en caché, las instalaciones posteriores son mucho más rápidas),
  • Soporte integrado para espacios de trabajo/arquitectura monorepo (alias, orquestación, etc.).

En el papel PNPM es una auténtica joya, pero los enlaces simbólicos eran un poco extraños de configurar correctamente (nuevamente, especialmente con React Native).

Ok, entonces nuestra elección estaba hecha, iríamos con PNPM.

Orquestación de guiones

Aunque PNPM agrega cada vez más orquestación a sus características, todavía no cubre todo lo que queríamos hacer, como por ejemplo:

  • construcciones secuenciales,
  • almacenamiento en caché.

Para estos, encontramos dos contendientes interesantes a los que necesitábamos echarle un vistazo:

  • NX (por el equipo angular),
  • turborrepo (que acaba de anunciar la v1.0.0 cuando empezamos a trabajar en ella y ahora trabaja con el equipo de Vercel).

Hicimos una prueba de concepto en ambos.

NX Tenía muchas más funciones, generadores, automatización, excelentes gráficos de dependencia, etc., pero agregaba muchos gastos generales y, dado que es bastante obstinado, tendríamos que seguir sus convenciones.

turborrepo por otro lado, tiene características bastante básicas. Sin embargo, es una solución conveniente plug and play que podríamos cambiar muy rápidamente si alguna vez fuera necesario.

Aunque turborrepo tenía menos características que NX, hizo las 2 cosas que estábamos buscando:

  • Orquestación de compilaciones respetando el árbol de dependencia (y compilaciones concurrentes),
  • Almacenamiento en caché (las compilaciones se almacenan en caché y se "reproducen" si su código no ha cambiado).

Eso, además de la fácil entrada y salida, nos hizo elegir al nuevo chico de la cuadra, TurboRepo.

Versiones

También analizamos varias soluciones, pero finalmente decidimos utilizar https://github.com/changesets/changesets ya que era una herramienta recomendada por TurboRepo y, después de leer un poco la documentación, parecía cumplir con nuestras necesidades.

Los desarrolladores tendrían que ser un poco más rigurosos en su flujo de desarrollo y proporcionar changesets (archivo que describe qué biblioteca cambia su código, la gravedad siguiendo el sever convención y una descripción del cambio). Estos changesets Luego se utilizan para aumentar automáticamente la versión de los paquetes respetando las gravedades dadas, así como para automatizar la generación de registros de cambios. Además de eso, las herramientas permiten pre release modo, el 🍒 en el 🍰.

¿Que sigue?

Después de decidir las herramientas, llegó el momento de empezar a trabajar. En el próximo artículo del blog, hablaremos sobre el sistema de compilación y todas las operaciones de desarrollo/automatización/integración continua en el contexto de un repositorio mono.


Valentín DE ALMEIDA
Experiencia de desarrollador y tecnología central: Ledger Live

Sello de tiempo:

Mas de Libro mayor