Historia de Dos Repositorios

Rate this content
Bookmark
Slides

Nem todos os monorepos são iguais, e nem todas as equipes são iguais.

Gerenciar um monorepo é muito mais do que apenas "vamos selecionar essa ferramenta ou aquela ferramenta". Envolve muitas decisões de design que você precisa tomar para o produto e para os desenvolvedores.


Nesta palestra, vou abordar os principais desafios dos monorepos - instalação e vinculação de pacotes, processos de desenvolvimento e implantação - e descrever as possibilidades que existem para cada etapa.


No final da palestra, você terá um modelo simples e poderoso que o ajudará a fazer a escolha certa de ferramentas e processos para o seu monorepo.

24 min
17 Apr, 2023

Video Summary and Transcription

JavaScript se tornou popular em meados de 2010 com a introdução do Node e frameworks avançados como Angular e React. Monorepos, que são repositórios únicos contendo vários artefatos, são uma abordagem popular para gerenciar projetos JavaScript. A vinculação de pacotes internamente em um monorepo pode ser feita por meio de instalação local ou global, ou publicando-os em um registro de artefatos. O gerenciamento de monorepos se tornou mais complexo com a introdução de ferramentas como TypeScript e Babel. O processo de desenvolvimento de aplicações web envolve um processo de compilação, testes e linting, que podem ser facilitados por ferramentas como Yarn Workspace e NPM Workspace. A estratégia de lançamento para monorepos pode ser unificada ou distribuída, e é importante selecionar ferramentas que estejam alinhadas com a estratégia escolhida.

Available in English

1. The Rise of JavaScript and Monorepos

Short description:

JavaScript se hizo popular a mediados de la década de 2010 con la introducción de Node y frameworks avanzados como Angular y React. En 2015, ECMAScript 6 (ES6) trajo nuevas características, pero los motores que ejecutaban el lenguaje no las admitían. Sebastian MacKenzie comenzó un proyecto para convertir el código ES6 para que pudiera ser utilizado en navegadores que admitieran ES5. El proyecto creció y se convirtió en Babyl, una decisión controvertida. Lerna, inicialmente sinónimo de Monorepos, se creó para gestionar los complementos del proyecto. Sin embargo, la forma en que usamos los Monorepos en 2015 puede no ser adecuada para el JavaScript moderno. Yarn y NX utilizan el término `workspace` de manera diferente. Tengo experiencia con Monorepos desde 2017.

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.

2. Decisions and Strategies for Monorepos

Short description:

Y no voy a hablar de esa herramienta o esa herramienta, Yarn o NX o TurboRepo. Al mover o tener un Monorepo, las decisiones y estrategias impactan en el proceso de desarrollo, la calidad del producto, la velocidad y la formación del equipo. Un Monorepo es un único repositorio que contiene múltiples artefactos como paquetes, servicios backend y aplicaciones frontend. La primera pregunta que debemos hacernos es qué incluir. No tiene que ser todo el código de la empresa. Otra decisión es si optar por un Monorepo. Si se elige, el repositorio incluirá múltiples artefactos con archivos package.json separados. La primera decisión se refiere a la instalación y al enfoque de agrupar los paquetes en la raíz del repositorio.

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.

3. Enlazando Paquetes en un Monorepo

Short description:

Significa que los paquetes en un monorepo pueden enlazarse internamente. Esto se puede hacer instalando el paquete local o globalmente. Otra opción es publicar los paquetes en un registro de artefactos e instalarlos desde allí. YARN también permite crear un enlace simbólico entre paquetes. Con la introducción de nuevas herramientas como TypeScript y Babel, la gestión de monorepos se ha vuelto más compleja.

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.

4. Desarrollo de Aplicaciones Web y Proceso de Construcción

Short description:

Para aplicaciones web, introdujimos herramientas como Webpack para el análisis estático de módulos. Sin embargo, apuntar directamente al código fuente plantea desafíos. En cambio, podemos apuntar al artefacto de construcción. El proceso de desarrollo se vuelve más complejo con la necesidad de un proceso de construcción, pruebas y linting. Herramientas como Yarn Workspace y NPM Workspace permiten que cada paquete ejecute pruebas de forma independiente.

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.

5. Configuraciones, Pruebas y Proceso de Construcción

Short description:

Podemos tener cada configuración separada en cada paquete, pero esto dificulta realizar cambios unificados en todo el proyecto. Otro enfoque es centralizar la configuración pero seguir ejecutando pruebas en cada proyecto. El proceso de construcción implica utilizar una clasificación topológica para ejecutar todas las construcciones en un orden lógico. Un enfoque avanzado es reconstruir solo los paquetes que han cambiado, utilizando control de origen y almacenamiento en caché para optimizar el proceso.

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.

6. Estrategia de Lanzamiento y Selección de Herramientas

Short description:

NX optimiza el proceso de construcción. La estrategia de lanzamiento es crítica. Dos enfoques: unificado (todos los paquetes bajo un mismo lanzamiento) y distribuido (versiones independientes). Comienza con el objetivo de lanzamiento, deriva estrategias de construcción y desarrollo, luego considera la vinculación e instalación. Selecciona herramientas que se ajusten a tu estrategia.

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.

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

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
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.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
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