Envía tu interfaz de usuario más rápido con Turborepo

Estás escribiendo, construyendo y enviando más código que nunca. Es genial construir un producto que tus clientes aman, pero tus tiempos de CI han estado aumentando lentamente. Tu experiencia de desarrollo local sigue empeorando un poco, y la complejidad de tu CI sigue aumentando. El tiempo que tarda desde la idea hasta el envío ha ido aumentando lentamente. Eso se debe a que tienes que sentarte y esperar por las cosas. Mucho como estos barcos. Pero ¿y si eso no tuviera que ser así? Hola y bienvenido a Turboverse. Soy Anthony. Soy TurboDX. Me gusta bromear diciendo que soy un comediante de pila completa, pero en realidad soy TurboDX. Estos problemas que describí son cosas en las que pienso mucho en mi trabajo. ¿Cómo podemos asegurarnos de que nunca hagas el mismo trabajo dos veces? Cuando necesitas hacer un trabajo nuevo, ¿cómo nos aseguramos de que sea rápido y que sea la menor cantidad de trabajo posible? ¿Cómo nos aseguramos de que desde el desarrollador individual hasta las aplicaciones enterprise más grandes del mundo, tengas una gran experiencia desde el principio hasta el final? En Turboverse, tenemos dos herramientas para lograr estos objetivos, TurboPak y TurboRepo.

Vamos a explorar TurboPak y hablar un poco sobre la arquitectura subyacente. Luego, nos sumergiremos en una demostración y utilizaremos ambas herramientas para enviar nuestro primer conjunto de aplicaciones con una capa de caché completamente distribuida. También hablaremos sobre cómo funciona este repositorio mecánicamente, los beneficios de los monorepos y las cosas a tener en cuenta a un nivel más alto al diseñar un monorepo.

Primero, sumerjámonos en TurboPak. TurboPak es un empaquetador incremental optimizado para JavaScript y TypeScript. Estamos escribiendo en Rust para obtener velocidades de metal desnudo, liderado por el creador de Webpack, Tobias Koppers. Además de esa velocidad bruta, también lo estamos haciendo más inteligente. Si me muevo aquí a los conceptos principales, verás información sobre el TurboEngine. Con el TurboEngine, estamos haciendo la menor cantidad de trabajo posible, como mencionamos antes. El TurboEngine cuenta con caché a nivel de función para que podamos hacer la menor cantidad de trabajo posible para crear los paquetes de tu aplicación. Anteriormente, en Webpack, solo podíamos hacer esto a nivel de módulo, a nivel de archivo. Pero con la caché a nivel de función, podemos comprender más profundamente los gráficos de tus módulos. Debido a que podemos analizar las relaciones en todo tu código de manera más profunda, podemos ser más rápidos y dirigirnos directamente a las cosas que necesitamos empaquetar, examinar y analizar, en lugar de crear un gráfico mucho más grande. Además, Webpack está diseñado de manera que crea primero un gráfico no optimizado y luego lo optimiza. En TurboPak, simplemente estamos haciendo ese gráfico optimizado la primera vez, como puedes imaginar, un poco más rápido. En el momento de esta grabación, estamos utilizando el servidor de desarrollo de Next.js como terreno de prueba para TurboPak. Puedes visitar areweterboyet.com para ver que no, aún no somos completamente Turbo. Estas son todas las pruebas que están en el empaquetador Webpack. Además, hemos agregado algunas más ahora que tenemos una mejor cobertura para TurboPak, para averiguar si el servidor de desarrollo de Next.js con TurboPak está listo para ser lanzado de la versión beta a la estable. Puedes ver que actualmente tenemos un 93,9% de aprobación en esas pruebas de Next.js. Pero una vez que terminemos allí, en realidad tendremos un buen comienzo para compilar para producción esas aplicaciones de Next.js con TurboPak. Puedes probar esto hoy en tu proyecto de Next.js 14 usando //Turbo en el script de desarrollo de tu aplicación de Next.js. Esperamos escuchar tu experiencia y agradeceríamos que si encuentras algún problema, informes esos errores en el repositorio de Next.js en GitHub.

Pero tu empaquetador es solo una parte de la historia. Ahora hablemos de TurboRepo y hagamos un poco de demostración y hablemos sobre algunos aspectos mecánicos. TurboRepo es un sistema de compilación de alto rendimiento para bases de código de JavaScript y TypeScript. Estamos aprovechando algunos de los conocimientos de las organizaciones de monorepo más grandes del mundo, como Meta y Google, y haciendo que esas técnicas sean amigables, utilizables y productivas para todos. A través de características como compilación incremental, caché remoto, ejecución en paralelo y mucho más, podemos hacer que tus compilaciones, linters, pruebas y cualquier otra tarea que necesites se realicen lo más rápido posible. Como prueba, aquí tienes una captura de pantalla rápida que tomé de Vercel.com para nuestro equipo de Vercel, que muestra cuánto tiempo hemos ahorrado en las últimas dos semanas. Parece que hemos ahorrado más de 8.500 horas.

Parece que hemos ahorrado casi más de 8,500 horas. Y lo que es aún mejor, todo este tiempo ahorrado es tiempo en el que tus ejecutores de tareas no están funcionando. Así que ya sea que sean GitHub Actions, Jenkins, GitLab CI CD, donde sea que estén, esas son máquinas que no tienen que hacer tanto trabajo.

Entonces, ¿cómo puedes configurarte para hacer esto también? Una forma sencilla es con npx create turbo at latest. Voy a ejecutar esto y se me pedirá algunas veces. Ya lo ejecuté en segundo plano para la demostración, pero esto tomará algunos archivos de GitHub y estarás configurado y listo para comenzar con tu propio monorepo.

Un consejo rápido, instala turbo globalmente. Si escribo turbo dash dash help aquí, verás que obtenemos nuestro texto de ayuda. Esto facilita mucho trabajar en un monorepo, y ahora que lo tengo disponible, puedo simplemente escribir turbo build, y comenzaremos a construir las dos aplicaciones en este monorepo en paralelo. Veremos que manejamos ambas compilaciones, sin problemas, en paralelo 14 segundos después.

También puedo agregar más tareas a la mezcla. Puedo agregar una lint junto a esas compilaciones, y estaré realizando lints en este repositorio en paralelo también. Pero notarás algo interesante aquí. Dos de estas tareas fueron en caché, y entre las cinco que ejecutamos, y aún mejor, puedo escribir turbo lint build, y obtendremos un turbo completo. Todo este trabajo lo hemos hecho antes, no hemos cambiado ningún código fuente, no hemos cambiado nada en este repositorio, entonces ¿por qué hacer ese trabajo nuevamente? TurboRepo también puede ayudarte durante el desarrollo, así que si escribo turbo dev, ejecutaremos nuestro script de desarrollo de documentos y nuestro script de desarrollo web al mismo tiempo, y esto en realidad me brinda una buena oportunidad para mostrar una cosa que nos encanta de los monorepos, que es que puedes usar una biblioteca compartida al mismo tiempo. Entonces, si abro el paquete UI aquí, adelante y tal vez edite este botón para poner un texto de prueba aquí. Fui y tomé un navegador para ver ahora, así que podemos ver aquí en esta aplicación web, tenemos este texto de prueba delante del texto real, y luego también podemos ir a 3001, donde se está ejecutando nuestra aplicación de documentos, y veremos documentos aquí y prueba haz clic en mí. Voy a eliminar eso, volver a donde estábamos, y puedes ver que eso se recargó en caliente en esa aplicación de documentos. Voy a tomar 3000 de nuevo, y puedes ver que la prueba también se ha ido aquí también. Mis cambios se propagan en un solo commit, y listo. Ahora somos mucho más rápidos durante el desarrollo, pero ¿qué pasa con la parte que realmente importa? El envío.

En solo unos minutos, puedo hacer que TurboRepo me ayude también en el momento del envío al construir un sistema de caché completamente distribuido que funciona en todas mis máquinas de CI, así como en mi máquina de desarrollo aquí también. Voy a demostrar esto usando GitHub y Vercel. Hay muchas otras iteraciones que puedes usar para conectar todas estas partes, pero esta es la forma más rápida para mí de hacer esto en el ámbito de una demostración, y puedo tener este sistema de caché listo en solo unos minutos. Lo primero es lo primero, necesito un repositorio al que enviar mi trabajo, así que voy a usar gh-repo-create. Voy a enviar un repositorio local aquí, y verás que esto sucede bastante rápido. Ni siquiera tuve que salir de mi terminal. Bastante conveniente. Y eventualmente usaremos esto para enviar nuestro trabajo a Vercel. Vercel utilizará la integración de Git y simplemente entenderá cuando haga cambios.

Lo siguiente que haré es utilizar vclink-repo. Y lo que hará es vincular mi repositorio de Git a un proyecto en Vercel. Así que seguiré adelante y elegiré uno. Necesito hacer ambos proyectos, así que lo haremos aquí. Y ahora que hemos creado ambos proyectos, están vinculados a mi repositorio que tengo aquí localmente.

Es bastante sencillo, pero como esto es un TurboRepo, ya estoy conectado en Vercel a mi repositorio aquí a través de la caché remota de Vercel. Así que si ejecuto turbo-build y hago un turbo completo, y si hago turbo-lint, hago un turbo completo de nuevo, ahora Vercel conoce estas cachés.

Otra cosa que puedo demostrar aquí rápidamente es que puedo hacer que las acciones de GitHub verifiquen y ejecuten este lint cuando envío código a una solicitud de extracción, y también verá la caché remota. Tomé el ejemplo que tenemos en la documentación de TurboRepo. Puedes ver que lo agregué a un flujo de trabajo de GitHub aquí. Creo que podría necesitar hacer algunos cambios aquí. No vamos a realizar una compilación. En su lugar, haremos lint, y ejecutaré el script de lint desde nuestro package JSON. Y aparte de eso, deberíamos estar listos para continuar.

Lo importante aquí es que esta acción de GitHub puede utilizar esa caché remota de Vercel de la que estábamos hablando. Así que si descomento estas líneas y termino, necesito obtener el secreto de mi TurboToken desde el panel de Vercel. Ya lo hice, tengo Turbo Team aquí y tengo mi secreto, el TurboToken, y ahora es el momento de hacer algunos envíos. Agregaré esto a un commit aquí. Creo que en realidad necesitaré salir de main, pero de todos modos haremos un commit inicial.

Haré checkout a DevOps JS. Perfecto. Luego seguiré adelante y crearé una solicitud de extracción. Si abro esta solicitud de extracción, en realidad obtendremos una descripción general a través de la cual podemos ver qué sucedió durante estas compilaciones. Creo que la primera que podemos ver es la tarea de CI. Esto era el lint, olvidé cambiarle el nombre. Pero si abro esta acción, veremos que las dependencias se instalarán. Y luego se ejecutará el lint. Y antes de que termine de leer el registro, ya está hecho. Parece que esto tomó, no sé, 15 segundos o algo así, pero este lint aparentemente tomó un segundo. Hizo un turbo completo porque no cambiamos ningún código.

Recuerda que ejecutamos estas verificaciones en nuestra máquina local, por lo que realmente no es necesario hacer ese trabajo nuevamente, ¿verdad? Solo porque estamos en una acción de GitHub. Así que ya conocemos el resultado de esto, simplemente lo restauramos desde la tarea correctamente.

También aquí, en nuestra aplicación de documentación, puedo continuar y parece que esto realmente también se completó antes de que terminara de explicar ese registro para la otra tarea. Pero parece que se construyó en 10 segundos porque, nuevamente, lo mismo. Tenemos un turbo completo.

Y si reviso este resumen de ejecución, esta es una característica interesante cuando tienes muchas más tareas que estás ejecutando. Podemos ver, por ejemplo, que ahorré 26 segundos de tiempo. Así que eso también es bastante conveniente. Ahora todo está desplegado y verificado. Y así, solo unos momentos después, puedo pasar directamente a la producción.

Has visto ese resultado final, es bueno volver atrás y pensar en diseñar y arquitecturar un monorepo ahora que sabemos que podemos ahorrar tiempo en todas partes. Así que pensemos en algunos principios de alto nivel.

Continuaré y tal vez haga algunas notas aquí, solo en un archivo de texto para que podamos anotar algunas cosas. Lo primero en lo que suelo empezar a pensar es que queremos utilizar la plataforma. Estás acostumbrado a escuchar esto en el mundo de JavaScript y la web como el navegador y las API web, pero también existen los ecosistemas de JavaScript y TypeScript que saben cómo utilizar los espacios de trabajo. Tienen expectativas y convenciones que podemos aprovechar. Podemos utilizar el poder de nuestro gestor de paquetes de node.js y de nuestras herramientas. Todas esas expectativas, podemos usarlas juntas y acelerar todas estas tareas. Ahí es donde se encuentra TurboRepo. Utilizamos todo dentro de tu repositorio. Es solo un envoltorio delgado alrededor de todo para ahorrarte mucho tiempo. Y cuando hacemos esto, obtienes un repositorio saludable a largo plazo, porque nuevamente, todo utiliza las convenciones y expectativas del ecosistema. Así que todo se mantiene rápido, fácil y conveniente desde el primer día hasta el día 100,000.

Otra cosa en la que me gusta pensar es que en un monorepo, los paquetes de mi aplicación y los paquetes de mi biblioteca casi empiezan a sentirse como un contexto de multi-repo. Así que los paquetes se sienten casi como multi-repos. ¿Qué quiero decir con esto? Ahora, hay límites para esta idea.

Por ejemplo, si realmente estuvieras trabajando en un multi-repo, tu aplicación web tendría su propio archivo de bloqueo. Eso no será el caso en un monorepo, ¿verdad? El archivo de bloqueo está aquí en la raíz y tu aplicación web está aquí abajo. Pero tal vez abra el archivo package.json de packages.ui aquí, y puedo demostrar que esto comienza a sentirse como su propio pequeño mundo, su propia caja casi autocontenida. Por ejemplo, estas exportaciones, hemos definido claramente lo que sale de este paquete UI. Estas son las tres cosas que están disponibles, nada más. Si accedes a este paquete, no estás haciendo lo que quieres hacer. Y otra cosa es que las dependencias se instalan donde se utilizan. Sabemos que ESLint se está utilizando aquí, sabemos que las configuraciones de nuestros otros paquetes de biblioteca, este espacio de trabajo estrella le está diciendo al NPM que esto está en nuestro repositorio. Así que terminas con esta historia donde el paquete UI es casi como su propio pequeño mundo, casi como su propio pequeño repositorio. Pero cuando sale al mundo exterior, cuando por ejemplo se utiliza en una de nuestras aplicaciones, es casi como si el paquete viniera del registro de NPM, cuando lo pensamos desde el lado del consumidor, ¿verdad? Se instala como un paquete de repositorio UI, y cuando lo usamos, se siente como algo que no vino de nuestro repositorio casi.

Ahora, quizás siguiendo estas dos ideas, lo ideal es tener la menor cantidad de dependencias en la raíz posible. Vale, esto puede sonar un poco extraño al principio para algunas personas, pero te prometo que esto es simplemente una mejor manera de trabajar cuando piensas en la salud a largo plazo de tu monorepo. Si abro este ejemplo de turbo repo aquí, el inicio, notarás que realmente no hay mucho aquí en cuanto a dependencias, ves turbo, ves prettier. Estas son cosas que operan fuera del contexto de las aplicaciones y los paquetes de biblioteca que están en tu repositorio.

Por lo tanto, tiene sentido que estén aquí arriba en la raíz. Luego, cuando quieras usar una dependencia del registro de NPM o cualquier otro lugar en tu repositorio, simplemente la instalas donde se utiliza. Por ejemplo, aquí estamos instalando next 14 en esta aplicación web. Esto es realmente importante por el simple hecho de que, ya sabes, tal vez tu equipo web y tu equipo de documentación quieran usar la misma versión de next, tal vez no quieran usar la misma versión de TypeScript. Hay razones completamente válidas para esto. Tal vez el equipo web necesite alguna función de TypeScript a partir de la versión 5.3.3 y superior que el equipo de documentación no pueda utilizar porque tal vez estén atrapados en la versión 4.0.

Tal vez no sea lo mejor para el equipo de documentación, pero al mismo tiempo, la realidad se impone y todos necesitan la agilidad y la flexibilidad para tener esta salida de emergencia para que todos puedan seguir trabajando sin tener que forzarse a utilizar las mismas versiones de las cosas. Esto es importante porque cuando trabajas a gran escala y tienes muchos equipos en el mismo monorepo, aunque la virtud de tener una versión de todo en el repositorio es ideal, la realidad se impone, ¿verdad? Nuestras aplicaciones deben llegar a los usuarios y cuando lo hacen, deben funcionar correctamente. Así que cuando tenemos estas diferentes versiones que podemos usar en todo el repositorio, tenemos un poco más de flexibilidad para seguir enviando y volver a esta actualización de TypeScript, por ejemplo, cuando tenemos la capacidad de hacerlo.

Por supuesto, hay compensaciones aquí. No diré que esa es la situación perfecta y que no hay costos en esa flexibilidad, pero si eres alguien que quiere mantener siempre TypeScript en la última versión, existen herramientas para esto, como pmpm up-r si estás usando pmpm, esta opción "-r es para decir recursivo y ahora, si ejecuto esto, obtendré TypeScript en la última versión en todo el repositorio. También hay herramientas como ManyPackage, si te has encontrado con esa, o SyncPack que pueden gestionar estas relaciones y mantener todo sincronizado automáticamente si así lo deseas. Además, estamos considerando la creación de funciones incorporadas en TurboRepo para hacer esto nosotros mismos. Probablemente se parecerá a TurboInstall, así que estate atento a eso.

Una última cosa que me gusta mencionar son los valores predeterminados sólidos con salidas de emergencia. Un ejemplo de esto sería probablemente TypeScript, por ejemplo, en este repositorio. Tenemos una configuración base de TypeScript que se debe utilizar en todo el repositorio. Estamos estableciendo buenos valores predeterminados aquí y queremos fomentar el uso de estos valores predeterminados en toda la aplicación. Ahora, por ejemplo, Next.js tiene un conjunto específico de opciones de compilador que necesita, tal vez una biblioteca de React en la que quieras establecer específicamente que quieres usar React.jsx. Como puedes ver a través de esta clave extends que tiene TypeScript, podemos hacer referencia a ese JSON base y utilizaremos todos estos valores predeterminados, pero podemos establecer los nuestros y agregar más y sobrescribir más. Y ahora, de nuevo, también podemos ir a las aplicaciones y comenzar a incluir y excluir cosas que tienen sentido para esta aplicación específica. De esta manera, tenemos estos buenos valores predeterminados. Nuevamente, ves la clave extends, estamos accediendo a esa configuración de TypeScript y utilizando Next.js.json, pero estamos haciendo cosas aquí que son específicas de esta aplicación. Se ha vuelto muy importante a gran escala. Tus desarrolladores saben qué esperar en todo el repositorio y tenemos flexibilidad aquí, pero también estamos reduciendo el código duplicado. Así que aquí tenemos lo mejor de ambos mundos. Pero incluso cuando seguimos este conjunto de estándares y principios, hemos creado buenos valores predeterminados con esas salidas de emergencia necesarias. ¿Cómo nos aseguramos de que toda nuestra organización utilice esos valores predeterminados y utilice de manera responsable esas salidas de emergencia? También hemos creado herramientas en Vercel para esto. Conformance y Codoners. Conformance es un verificador de análisis estático que automatiza cosas como el rendimiento, la seguridad, la calidad y las mejores prácticas dentro de tu repositorio.

Esto va más allá de ESLint como un verificador de análisis estático, porque se ejecuta en varios archivos al mismo tiempo e informa sobre esos archivos individuales. Además, viene con un conjunto de reglas que recomendamos en Vercel, y también puedes escribir las tuyas propias.

Lo que viste allí en el video también fue la función de Codoners. Puedes imitar la estructura de tu organización directamente en tu repositorio para asegurarte de que las personas adecuadas realicen las revisiones adecuadas en el código adecuado en el momento adecuado. Automatizar ese proceso también es muy valioso.

Creo que lo que más me gusta de estas funciones es que ni siquiera tienes que implementar tus aplicaciones en Vercel para poder utilizar estas características. Nunca veremos tu código fuente, por lo que si tienes un alto estándar para poder compartir el código fuente en tu organización, aún puedes aprovechar estas funciones. Creo que lo otro que más me gusta es que ni siquiera tuve que hacer una diapositiva para esto porque el equipo de design hizo este gran video. Si estás experimentando problemas en tu sistema de CI donde las cosas simplemente no son tan rápidas y deseas que sean más rápidas y dejar de hacer el mismo trabajo una y otra vez, entonces espero que TurboRepo te resulte inspirador, y espero que TurboPak te haya emocionado por el futuro de los empaquetadores para la web. Soy Anthony, y espero que tengas un excelente resto de tu DevOps.jsConf.