Potenciando los Monorepos con los Espacios de Trabajo de npm

Rate this content
Bookmark

Aprende más sobre cómo aprovechar las características predeterminadas de los espacios de trabajo de npm para ayudarte a gestionar tu proyecto de monorepo mientras también exploras algunas de las nuevas características de la línea de comandos de npm.

25 min
20 Jun, 2022

Video Summary and Transcription

Esta Charla proporciona una introducción a los Espacios de Trabajo de npm y cubre varios aspectos de su uso, incluyendo cómo iniciar un espacio de trabajo con npm init, agregar dependencias, forzar versiones correctas de bibliotecas, ejecutar scripts y orquestar en un monorepo, y utilizar npm pkg y npm exec. Los ejemplos proporcionados demuestran casos de uso reales y resaltan la flexibilidad y el control que ofrecen los Espacios de Trabajo de npm. El orador también menciona mejoras y desarrollos futuros en la CLI de npm, enfatizando la importancia de las declaraciones correctas en el archivo package.json y la capacidad de gestionar datos en todos los espacios de trabajo.

Available in English

1. Introducción a los Espacios de Trabajo de NPM

Short description:

Hola, y bienvenidos a la Masterclass de NPM Workspaces. Permítanme comenzar presentándome. Mi nombre es Rui Adorno. Soy un desarrollador de software en el equipo de NPM CLI de GitHub. He estado trabajando en NPM CLI durante casi tres años. Trabajo en la reescritura de NPM v7 y muchas de las características de las que hablaremos hoy, especialmente los espacios de trabajo.

Hola, y bienvenidos a la Masterclass de NPM Workspaces. Permítanme comenzar presentándome. Mi nombre es Rui Adorno. Soy un desarrollador de software en el equipo de NPM CLI de GitHub. He estado trabajando en NPM CLI durante casi tres años. Trabajo en la reescritura de NPM v7 y muchas de las características de las que hablaremos hoy, especialmente los espacios de trabajo. Estoy muy emocionado de compartir parte de ese trabajo con ustedes hoy.

Y comencemos con una descripción general de lo que vamos a cubrir hoy. Comencemos con una introducción a qué son los Espacios de Trabajo de NPM y luego cubriremos algunos ejemplos prácticos que se acerquen lo más posible al uso en la vida real, y también mencionaremos algunas de las cosas a las que deben estar atentos. Así que, empecemos.

Los Espacios de Trabajo de NPM. ¿Qué es eso? Comencemos con los Espacios de Trabajo, que es básicamente un concepto introducido por Yarn hace un tiempo, y básicamente es una forma de ayudarte a gestionar muchos paquetes dentro de un solo repositorio. Y para NPM, los Espacios de Trabajo de NPM es el nombre general que le dimos al conjunto de características que te ayudan a lograr eso. Básicamente te ayuda a gestionar múltiples paquetes anidados dentro de un solo paquete de nivel superior. Por lo tanto, te ayudará a centralizar la instalación de todas las dependencias en una sola carpeta de Node Modules, por lo que también terminarás teniendo solo un archivo de registro de paquetes. Y hay algunas ventajas en eso. Definitivamente es la forma ideal de gestionar Monorepos, y gracias a eso, puedes tener un solo lugar para gestionar todos tus problemas y básicamente gestionar tu proyecto y tu comunidad. Pero también desde el lado técnico, también puedes centralizar, tener un solo lugar para ejecutar todas tus pruebas, pares, linting, cualquier cosa que puedas imaginar. Necesitas tener todo junto para que tu proyecto funcione con todos los paquetes. Puedes tenerlo todo en un solo lugar. Por lo tanto, puede ser de gran ayuda dependiendo del estilo del proyecto que estés tratando de lograr. Otra cosa que me gustaría mencionar aquí es la línea de tiempo, solo para dar un poco de noción de cómo hemos estado mejorando iterativamente en los Espacios de Trabajo de NPM. Y puedes ver que todo comenzó en agosto de 2020 con el lanzamiento de la versión 7.0 de NPM CLI, que introdujo por primera vez el soporte para instalar los Espacios de Trabajo de NPM. Y luego, en la versión 7.7, otro gran avance que introdujo las propiedades de configuración de un espacio de trabajo o que apuntan a todos los espacios de trabajo y el primer comando que los admite con NPM run y NPM exec. No hubo muchos más, pero solo quería ilustrar cómo hemos estado mejorando y definitivamente puedes esperar ver más mejoras en los Espacios de Trabajo de NPM.

Entonces, comencemos con algunos ejemplos aquí. Tengo este proyecto que tengo a la izquierda aquí, que es una aplicación de muestra que he creado tratando de acercarme lo más posible a un proyecto de la vida real. Es una especie de aplicación web que consta de dos servicios diferentes. Puedes ver que tengo mi servicio de sincronización de usuarios, mi servicio de aplicación web e incluso configuro un tercer espacio de trabajo aquí, que son las diapositivas que estás viendo ahora mismo. Todos forman parte de este monorepo que estoy gestionando aquí.

2. Usando npm init para comenzar un Espacio de Trabajo

Short description:

Y con eso, espero poner algunos ejemplos que se acerquen mucho a cómo usarías esto en tu vida real. Así que puedes ver que todos tienen un montón de dependencias aquí usando Next.js, los servicios usando Fastify. Avanzando, me gustaría resaltar npm init. Probablemente sea la mejor manera de comenzar tu espacio de trabajo porque se asegurará de que cada paso necesario esté presente.

Y con eso, espero poner algunos ejemplos que se acerquen mucho a cómo usarías esto en tu vida real. Así que puedes ver que todos tienen un montón de dependencias aquí usando Next.js, los servicios usando Fastify. Así que puedo comenzar rápidamente ejecutando npm ls aquí y podemos ver cómo, y ls es un comando que conoce los espacios de trabajo y resaltará cada uno de los espacios de trabajo en mi proyecto e incluso enumerará las dependencias de cada espacio de trabajo cuando ejecute un npm ls. Por lo tanto, es el primer comando que tiene soporte de primera clase para los espacios de trabajo.

Avanzando aquí, me gustaría resaltar npm init. Probablemente sea la mejor manera de comenzar tu espacio de trabajo porque se asegurará de que cada paso necesario esté presente. Básicamente, todo lo que necesitas para rastrear un paquete anidado como un espacio de trabajo es asegurarte de tener la carpeta con un archivo package JSON dentro de ella, dentro de tu proyecto, y luego agregar el nombre de la carpeta a tu campo de workspaces en tu archivo package JSON en el nivel superior. Por lo tanto, usar npm init se asegurará de que esos requisitos estén presentes. Voy a ejecutar un ejemplo rápido aquí en mi aplicación de muestra, voy a crear un nuevo espacio de trabajo. Digamos que lo llamaré `website`. Así que puedo ejecutar npm init, estoy usando -Y aquí para aceptar todas las opciones predeterminadas y estoy apuntando a un sitio web. Eso creará una carpeta `website` con un archivo package.json dentro de ella, y mostrará el contenido del archivo package.json aquí. Y como mencioné antes, el otro punto realmente importante que npm init se encarga es colocar la referencia al `website` dentro de mi archivo package.json en mi carpeta de nivel superior. Con eso, todo está configurado. Si ejecuto npm install aquí, ahora el árbol de instalación rastreará el `website`. Y si vuelvo a ejecutar npm ls, veré que `website` está listado como uno de los espacios de trabajo aquí resaltado en verde. Esa es definitivamente la forma recomendada de comenzar con un nuevo espacio de trabajo dentro de tu proyecto.

3. Agregando Dependencias a los Espacios de Trabajo

Short description:

Y podemos pasar a otro aspecto muy importante. ¿Cómo agregas dependencias a uno de tus espacios de trabajo? Un ejemplo rápido aquí, voy a apuntar al sitio web que acabo de crear e instalar el paquete Simple Slider en mi sitio web. Ese es uno de los conceptos más importantes de los espacios de trabajo de npm: todo intenta ser elevado tanto como sea posible. Sin embargo, si hay duplicaciones, es posible que termines con una carpeta node_modules dentro de tu espacio de trabajo que deduplica esos paquetes. Para los espacios de trabajo de npm, actualmente estamos siguiendo una nueva función para dar a los usuarios más control sobre dónde se colocan las dependencias. En mi aplicación de muestra, me encontré con un escenario en el que la biblioteca Prisma Client no funcionaba cuando se elevaba al nivel superior de mi aplicación. Duplicarlo en las carpetas de servicio resolvió el problema.

Y podemos pasar a otro aspecto muy importante. ¿Cómo agregas dependencias a uno de tus espacios de trabajo, ¿verdad? Un ejemplo rápido aquí, nuevamente, voy a cambiar la configuración del espacio de trabajo aquí. Así que puedes ver que prácticamente puede ir a cualquier lugar. Simplemente puedo declarar el espacio de trabajo de npm. Voy a apuntar al sitio web que acabo de crear. Y digamos que quiero instalar un paquete. Voy a instalar este paquete Simple Slider en mi sitio web. Así que puedo ejecutar ese comando. Lo que va a hacer es instalar el paquete Simple Slider desde el registro. Lo va a colocar como una dependencia de mi espacio de trabajo del sitio web. Puedo buscar su package.json. Y puedo ver que Simple Slider está declarado aquí como una dependencia. Pero si busco en la carpeta node_modules en el nivel superior de mi aplicación monorepo, puedo ver que Simple Slider se colocó allí. Básicamente, ese es uno de los conceptos más importantes de los espacios de trabajo de npm: todo intenta ser elevado tanto como sea posible. Solo evita esa elevación o ese traslado de un nivel cada dependencia si encuentra duplicaciones. Así que si hay duplicaciones, es posible que termines con una carpeta node_modules dentro de tu espacio de trabajo que deduplica esos paquetes para que funcione como se espera. Así que todo eso para mencionar una cosa que he visto como algo común con los espacios de trabajo es que algunas personas solían tener esta opción de configuración no hoist que era una opción que Yarn introdujo para básicamente hacer que los espacios de trabajo dijeran: `De acuerdo, necesito esta dependencia, pero necesito asegurarme de que esté dentro de una carpeta node_modules dentro de mi espacio de trabajo`. Debido a la naturaleza de algunos módulos, algunos paquetes, realmente necesitan depender del hecho de que están en esa posición en el sistema de archivos. Eso es algo con lo que ya te encuentras para básicamente dar una salida a los usuarios para tener un poco más de control sobre dónde se coloca en sus dependencias. Para los espacios de trabajo de npm, actualmente estamos siguiendo eso como una nueva función. Lo estamos discutiendo en nuestros procesos de RFC. Y estamos deseando proporcionar a los usuarios una forma de hacerlo. Aún no estamos seguros si vamos a usar ese mismo valor de configuración no-hoist, o si será algo diferente. Pero mientras tanto, quería proporcionar una forma de desbloquearte si alguna vez te encuentras con ese escenario. En mi aplicación de muestra aquí, realmente me encontré con eso. Estoy usando este Prisma Client, que es esta biblioteca para administrar, básicamente, es un ORM para esa base. Y lo estoy usando en ambos servicios de mi aplicación de muestra. Y cuando se elevó al nivel superior de mi aplicación, básicamente no funcionó. Una forma rápida de desbloquearme y hacer que funcione es duplicarlo y tenerlo en ambas carpetas de mis servicios, dentro de sus node_modules. Así que una forma rápida de lograr esa duplicación fue básicamente poner algún paquete simulado aquí, que básicamente entraría en conflicto con el espacio de nombres del paquete que están usando. Así que he usado Prisma y Prisma Client, y los he declarado usando alias de NPM y apuntando a algo más.

4. Forzando Versiones Correctas de Bibliotecas

Short description:

Para asegurar que se instalen las versiones correctas de las bibliotecas, es importante tener las declaraciones correctas en el archivo package.json. Esto garantizará que las carpetas necesarias se coloquen en la ubicación correcta y evitará cualquier problema con la elevación. Si bien actualmente existen soluciones alternativas disponibles, vale la pena señalar que podrían haber mejoras en el soporte predeterminado de NPM-CLI en el horizonte.

En mi caso aquí, estoy usando este módulo abraham, pero realmente puede ser cualquier cosa. Y esto es para asegurarme de que cuando lo declare en mi servicio de usuario, tenga la declaración correcta de las versiones esperadas que tengo para estas bibliotecas. Para que cuando NPM instale, realmente coloque las carpetas del cliente Prisma dentro de mis módulos de nodo de usuario. Es básicamente una forma de forzar ese mismo comportamiento de no elevación y podría ayudar a bloquear a otros usuarios allí, por lo que es una forma muy práctica de comenzar hoy, pero definitivamente mantén un ojo porque definitivamente hay cosas en marcha. Podría mejorar muy pronto en el soporte predeterminado de NPM-CLI.

5. Ejecución de Scripts y Orquestación en un Monorepo

Short description:

Avanzando, quiero cubrir la ejecución de scripts y proporcionar ejemplos de cómo ejecutarlos. Puedes ejecutar scripts utilizando el nombre del espacio de trabajo o el nombre de la ruta del espacio de trabajo. También muestro cómo ejecutar pruebas para un espacio de trabajo específico y cómo orquestar scripts en un monorepo más complejo. Utilizo el paquete npm run all para ejecutar múltiples scripts y proporcionar flexibilidad. Demuestro cómo ejecutar scripts de prueba y desarrollo para diferentes espacios de trabajo, y cómo ejecutar scripts de desarrollo en paralelo utilizando npm run all. El resultado es un servidor de desarrollo en ejecución con una aplicación web funcional.

Avanzando, también quiero cubrir la ejecución de scripts y aquí también coloco algunos ejemplos de cómo puedes ejecutarlos. Puedes ejecutarlos utilizando el nombre del espacio de trabajo, también un ejemplo si tu espacio de trabajo tiene un ámbito, entonces también debes definir el ámbito, pero también puedes llamarlo utilizando el nombre de la ruta del espacio de trabajo.

Básicamente, en mi proyecto aquí, puedo mostrar rápidamente si apunto a ese espacio de trabajo de servicio de sincronización de usuarios que tengo y ejecuto sus pruebas, puedes ver que se ejecutarán las pruebas para ese espacio de trabajo y es básicamente lo mismo que navegar hasta la carpeta de ese espacio de trabajo y ejecutar npm test dentro de él. Sí, y básicamente quiero avanzar aquí a ejemplos un poco más complejos que he reunido, básicamente mostrando cómo en un monorepo más complejo puedes orquestar tus scripts de manera que puedan ser mucho más útiles.

Comenzando rápidamente aquí, siguiendo el ejemplo de prueba que acabo de dar. Este es un ejemplo. Estos son los scripts de mi archivo package JSON de nivel superior. Estoy declarando esta columna de prueba para la aplicación web y esta columna de prueba para el usuario, nombrada según cada uno de mis espacios de trabajo. Así que básicamente llaman a las pruebas y apuntan a cada uno de los espacios de trabajo. De esta manera, tengo estos múltiples scripts en mi comando de nivel superior. Voy a utilizar este archivo binario run-ass que en realidad proviene de este paquete de usuario llamado npm run all. Lo anoté aquí. Es un paquete muy útil. Te ayuda a ejecutar múltiples scripts y te brinda mucha más flexibilidad en la forma en que lo haces. Básicamente, le estoy diciendo a run-ass que ejecute todos mis objetivos de prueba definidos aquí en mi archivo. Así que volvamos a mi carpeta raíz aquí y ejecutemos npm test y veamos qué sucede. Puedes ver que se ejecuta primero el objetivo de prueba de la aplicación web, que ejecuta la prueba dentro de ese espacio de trabajo. Y luego, después de eso, ejecutas la prueba de sincronización de usuarios, que ejecutó la prueba para ese espacio de trabajo de sincronización de usuarios, y puedes ver que tuvo éxito. Un poco más evolucionado, pero siguiendo el ejemplo anterior, también ejecutemos mis servidores de desarrollo aquí. Tengo algo similar, dev para la aplicación web y para usersync, y estoy apuntando a npm run en mis espacios de trabajo y ejecutando el script de desarrollo de cada uno de ellos. Pero la particularidad de los servidores es que necesito que todos estén en ejecución al mismo tiempo, ¿verdad? Esto también es algo proporcionado por npm run all, que voy a usar para ejecutar, usando run-p, que va a ejecutar ambos objetivos en paralelo. Simplemente los iniciará todos al mismo tiempo, los mantendrá en ejecución para que pueda tener todo en funcionamiento y realmente usar mi servidor de desarrollo, navegar por mi interfaz de usuario. Así que probémoslo rápidamente aquí. Voy a ejecutar npm run dev. Puedes ver que ejecuta todos los scripts y sus dependencias. Voy a avanzar aquí. Esta siguiente diapositiva en realidad apunta al servidor que se está ejecutando en mi localhost. Y ahora, una vez que todo esté en funcionamiento, puedo ver que mi lista de usuarios está de vuelta. Puedo ver algunos usuarios, puedo hacer clic, navegar, y puedo ver que mi aplicación web funciona como se esperaba. Aquí quiero resaltar este nuevo comando, algo nuevo.

6. Uso de npm pkg y npm exec

Short description:

Introdujimos un comando para ayudar a establecer y recuperar claves y valores de los archivos package.json. Es súper útil en el contexto de los espacios de trabajo. Puedes usarlo para imprimir el contenido de package.json y filtrar propiedades. Puede recuperar el nombre y la versión de todos los espacios de trabajo, establecer datos en los archivos package.json y gestionar datos en todos los espacios de trabajo. npm version y npm publish también admiten espacios de trabajo, lo que te permite crear nuevas versiones de parche. Ten en cuenta que npm version funciona de manera diferente ahora, con menos confirmaciones y etiquetas. Se esperan mejoras en npm version. Para concluir, aquí tienes un ejemplo rápido utilizando npm exec.

Lo introdujimos a finales del año pasado en la versión 7.20, y es un comando que te ayuda a establecer y recuperar claves y valores de tus archivos package.json. No solo es útil en el contexto de los espacios de trabajo, sino que es súper útil cuando se utiliza en el contexto de los espacios de trabajo.

Se puede utilizar para, déjame resaltar aquí rápidamente. Si ejecutas npm pkg get, puede ser solo un paquete simple. Básicamente imprimirá el contenido de package.json. Y también puedes filtrar las propiedades, digamos, el nombre, y luego obtengo el nombre de mi paquete allí.

Cuando se agrega el soporte para las propiedades de los espacios de trabajo, puede volverse realmente poderoso. Como en este ejemplo aquí, voy a recuperar el nombre de la versión de todos mis espacios de trabajo. Esta opción de configuración aquí, --WS, es básicamente una forma de decir, ok, apunta a todos mis espacios de trabajo configurados. Si lo ejecuto, puedes ver que devuelve el nombre de la versión de cada uno de mis espacios de trabajo. Y incluso están clasificados por el nombre del espacio de trabajo. Así que puede ser realmente útil.

Y también para resaltar un poco más cómo pueden ser útiles, déjame también establecer algunos datos en estos archivos package.json. Digamos que estoy gestionando este proyecto y es un proyecto de código abierto. Solo quiero mostrar información sobre cómo los usuarios pueden financiar mi trabajo. Así que puedo usar npm pkg set. Y digamos que voy a establecer una clave de financiamiento en todos estos package.json. Luego lo voy a vincular a mi URL de patrocinadores de GitHub y voy a apuntar a todos los espacios de trabajo configurados. Así que puedo ejecutar eso. Y si buscas, digamos, mi package.json de usersync, puedes ver que la información de financiamiento está ahí ahora. Lo mismo ocurre con mi package.json de la aplicación web. Puede ser una forma increíblemente poderosa de ayudarte a gestionar todos esos datos en tu package.json en todos los espacios de trabajo configurados.

También quiero destacar aquí que npm version y npm publish también admiten espacios de trabajo. Entonces, si quieres crear, digamos, una nueva versión de parche de un espacio de trabajo, eso es posible hoy. Y algo a tener en cuenta es, como puedes ver aquí, aumenté mi versión a v1.0.1. Puedo buscar mi package.json allí y ver que la versión está ahí, pero una cosa a tener en cuenta que es un poco diferente ahora de la forma en que npm version funciona de forma predeterminada es que no hay muchas confirmaciones y etiquetas cuando se ejecuta npm version. Así que es algo a tener en cuenta, pero definitivamente puedes esperar mejoras en npm version específicamente.

Para resumir todo, quería hacer un ejemplo rápido aquí. Estoy usando npm exec. Es básicamente npx.

7. Uso de npm exec y npm run en Espacios de trabajo

Short description:

Se promocionó como un subcomando en la CLI de npm desde la versión siete. Llamémoslo imprimir el directorio de trabajo actual. Usaré exec para ejecutar este espacio de trabajo como un comando en todos los demás espacios de trabajo. Quiero resaltar cómo funciona npm exec o npm run en el contexto de cada carpeta. Establecí un valor binario de Index.js para el espacio de trabajo imprimir CWD, asegurando un seguimiento adecuado del archivo binario. Al ejecutar npm exec, puedo llamar a mi módulo para que se ejecute en cada espacio de trabajo, produciendo el resultado esperado de imprimir la ruta de cada espacio de trabajo. Para obtener más información, consulta la documentación oficial o encuéntrame en Twitter, GitHub o mi sitio web.

Se promocionó como un subcomando en la CLI de npm desde la versión siete. Y quería crear rápidamente otro espacio de trabajo. Llamémoslo imprimir el directorio de trabajo actual. Y voy a usar exec para ejecutar este espacio de trabajo como un comando en todos los demás espacios de trabajo que tengo configurados, juntando todo usando todos los comandos que acabamos de ver.

Así que déjame ir rápidamente a esa carpeta y comenzar el archivo index.js. Este archivo index.js simplemente imprimirá el directorio de trabajo actual. Esto será útil porque quiero resaltar cómo funciona npm exec o npm run. Se ejecutan en el contexto de cada carpeta. Así que quiero imprimir el directorio de trabajo actual solo para asegurarme de eso. La próxima vez, voy a establecer un valor binario de Index.js para el espacio de trabajo imprimir CWD que acabo de crear, para que se rastree correctamente ese archivo binario, Index.js. Y ahora voy a instalar npm para juntarlo todo, asegurarme de que mi binario esté correctamente vinculado a mi carpeta de módulos de Node. Y ahora puedo ejecutar npm exec y voy a llamar a mi módulo y le diré que se ejecute en cada uno de los espacios de trabajo. Y puedes ver que obtuve el resultado esperado aquí. Básicamente, imprimió la ruta de cada uno de mis espacios de trabajo cuando se ejecutó dentro de ellos. Así que aquí tienes un ejemplo rápido para cerrar, resumir y juntar todo, cómo puedes usar todos estos comandos.

Si quieres obtener más información al respecto, definitivamente consulta la documentación oficial. Tenemos una sección exclusiva sobre los espacios de trabajo, pero también hay documentación sobre cada uno de estos comandos que explica un poco más cómo usarlos. Y si quieres encontrarme, soy Rui Adorno en Twitter o GitHub. Y aquí también está mi sitio web. Realmente espero que esto haya sido útil y que los ejemplos de la vida real sean muy buenos. Espero que lo disfrutes. 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

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.
React Summit 2022React Summit 2022
21 min
Scale Your React App without Micro-frontends
As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!
JSNation 2022JSNation 2022
25 min
The Age of Monorepos
The history of the web can be divided into evolutionary development leaps. The age of inline scripts, the age of jQuery, the age of SPAs, the age of JAMStack...We are now entering the next stage that has been carefully prepared in the past few years. Let me invite you to the world of modern monorepo solutions and share with you the benefits you will reap by using them in every project size and setup. It's time you automate those boilerplate tasks and reduce the bottlenecks so you can focus on what truly matters.Get ready for the next leap! Welcome to the age of monorepos!
Remix Conf Europe 2022Remix Conf Europe 2022
22 min
Remixing Your Stack in a Monorepo Workspace
Remix entered the stage with a unique and refreshing take on how to develop on the web. But how do you integrate it into your existing ecosystem of applications? Do you want to test-drive Remix on a small project, or do you want to go full-in, but it is tricky to do a big-bang migration from your existing React app? In this talk, we're going to explore how a monorepo-based code organization can help integrate Remix with your existing React and TypeScript infrastructure, facilitating high code reuse and a migration path to Remix.

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
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
WorkshopFree
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app https://github.com/snyk-labs/nodejs-goof, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.
React Summit 2022React Summit 2022
51 min
Build Web3 apps with React
WorkshopFree
The workshop is designed to help Web2 developers start building for Web3 using the Hyperverse. The Hyperverse is an open marketplace of community-built, audited, easy to discover smart modules. Our goal - to make it easy for React developers to build Web3 apps without writing a single line of smart contract code. Think “npm for smart contracts.”
Learn more about the Hyperverse here.
We will go over all the blockchain/crypto basics you need to know to start building on the Hyperverse, so you do not need to have any previous knowledge about the Web3 space. You just need to have React experience.