El Núcleo de Turbopack Explicado (Live Coding)

Gracias por invitarme. Estoy intentando algo nuevo. Estoy intentando hacer codificación en vivo hoy, así que espero que funcione. Así que, sí, mi nombre es Tobias Koppers y trabajé en Webpack durante 10 años y ahora, junto a Universal, trabajo en TurboPack intentando hacer algo nuevo, algo mejor y sí, estoy intentando centrarme, como he dicho, estoy intentando centrarme en un aspecto de TurboPack e intentar explicar un poco cómo funciona TurboPack o el núcleo de TurboEngine en detalle, así que estoy intentando demostrar algo con eso, así que estoy intentando realmente intentar codificar en vivo en JavaScript un poco del núcleo de TurboEngine.

Así que la motivación de eso es que en las aplicaciones de Webpack vimos que las aplicaciones crecen y crecen, más y más grandes y Webpack, la arquitectura de Webpack no está construida para eso, las compilaciones incrementales tienden a volverse más lentas y más lentas si la aplicación crece. No es un problema tan grande, pero sí, podría convertirse en un problema en unos años cuando las aplicaciones tengan millones de módulos o lo que sea y algunos problemas que aislamos fueron hacemos muchas búsquedas de caché, tenemos que calcular muchas cosas para hacer la validación de caché como verificar si los archivos siguen siendo los mismos, hacer hash de cosas y ese es el problema porque todo este sobrecarga, lo pagas por cada compilación incremental y queremos hacer algo nuevo, una nueva arquitectura para abordar este problema. Y por eso creamos como turbo engine y turbo pack y es una nueva arquitectura y puedo explicarlo un poco haciendo codificación en vivo.

Lo que quiero mostrar es una especie de pequeña aplicación que es súper simple, no un empaquetador sino algo que es similar a un empaquetador, está tomando cualquier aplicación de JavaScript y simplemente copia la aplicación siguiendo el gráfico de dependencias a otra carpeta y al hacerlo también agrega un encabezado de derechos de autor solo para demostrar algo. Con eso, comienzo con la aplicación básica escrita en JavaScript y la explico más tarde y luego intento agregar algo similar a TurboEngine para hacerlo más eficiente, para hacer posibles las compilaciones incrementales de una manera similar a como funciona en TurboPack, en Rust y con TurboEngine. Para eso preparé esta pequeña aplicación, es realmente simple, es solo un montón de Node.js Usamos Acron para obtener el gráfico de dependencias de algo, la ruta allí, los módulos.

Y repaso la aplicación un poco para que la entiendas. El proceso principal es realmente simple, obtenemos el directorio base, como el directorio fuente, tenemos un directorio de salida, y luego tenemos un archivo de entrada que es realmente este archivo que estamos viendo. Así que realmente estamos copiando su propia aplicación a otra carpeta. Y luego comenzamos a seguir el gráfico de dependencias desde ese punto de entrada y copiamos eso del nivel base al nivel de salida. Y otro, para hacerlo un poco más complicado, agrego este archivo de encabezado que básicamente es, déjame mostrarlo, es como una declaración de derechos de autor que debería agregarse a cada archivo para hacerlo un poco más interesante. Así que luego invocamos este tipo de función, copiar gráfico, que básicamente calcula la salida del archivo actual simplemente reubicándolo. Llamando a la función de copia que copia el archivo, súper simple. Y luego llama a otras dos funciones que se llaman obtener referencias que veremos más tarde, es como obtener las referencias, como todos los archivos que han sido importados de un archivo y luego recorrer eso y llamarse a sí mismo recursivamente para simplemente copiar toda la aplicación. Sí. Así que copiar también es bastante simple, leer el encabezado, leer el archivo y escribirlo en otro archivo. Nada súper complicado aquí. Obtener referencias es un poco más complicado pero sí, no es realmente que tengas que entenderlo. Es como llamar a parse para obtener un AST del módulo y como recorrer o hacer algo de magia para extraer las declaraciones de importación y devolver una lista de todos los archivos referenciados por ese tipo de archivo. Parse también es bastante simple usando llamar a Akon, que es una biblioteca de análisis de JavaScript. También leer el archivo obviamente y luego devuelve el AST. Y después de eso comienzo todo y eso debería copiar la aplicación a la nueva carpeta. Así que intentémoslo. Oh. Algunas cosas que quiero explicar. También tengo esta función de tarea que actualmente no está haciendo nada.

Así que básicamente solo se está añadiendo algo de registro para que puedas ver lo que la aplicación está haciendo. De lo contrario, simplemente no imprime nada, eso es bastante aburrido. Así que solo tiene registro y lo que hago es básicamente llamar a la función con registro. Lo ves pero no es nada directo, no está haciendo nada especial.

Añadimos más lógica a eso más tarde. Así que lo que terminarás viendo es toda esta aplicación ejecutándose, así que está llamando a main, llamando a copy graph, llamando a copy y llamando a todas estas funciones en tres tipos de metales. Esto es básicamente un seguimiento de pila.

Pero también ves muchos problemas con esta aplicación. Por ejemplo, estamos leyendo el encabezado un montón de veces, como aquí y aquí y aquí. Y también estamos llamando a copy graph múltiples veces. Estamos llamando a fs copy graph desde taskKey, porque está referenciado desde fs. Y estamos llamando a copy graph desde task. Así que estamos haciendo mucho trabajo duplicado que no queremos hacer trabajo duplicado porque eso es lo que queremos hacer.

El primer paso es básicamente añadir algún tipo de sistema de memorización que es como una caché. Así que si ejecutas la misma función dos veces, entonces simplemente devolvemos un resultado existente. Así que añadamos eso. Así que para añadir algo de caché, almacenamos la caché en algún lugar. Y en JavaScript, podemos simplemente usar un mapa para eso. Y lo que queremos hacer es obtener la tarea del mapa como primer paso, la función de la caché. En realidad queremos obtener la función y todos estos argumentos. Así que porque puedes llamar a la misma función con diferentes argumentos, lo cual es básicamente una tarea diferente. Y luego si tenemos una tarea, y podemos simplemente, si no tienes una tarea, podemos simplemente crear una. Lo que significa que creamos un nuevo objeto, que tiene algún resultado, que es indefinido para el y luego establecemos el resultado, que es básicamente lo que estábamos haciendo antes, así que copia eso aquí aquí. Y luego, en cualquier caso, devolvemos el resultado. Así que ahora deberíamos tener algún tipo de sistema de memorización.

Me perdí algunas cosas, así que en realidad tengo que establecer la caché, sí, así. Y hay un error, probablemente lo veas si eres un desarrollador de JavaScript, el mapa no funciona con matrices porque se almacena por identidad, así que lo que realmente necesitamos hacer es almacenarlo por un tipo de valor de eso, así que para eso preparé algo que es como un TupleMap. Que necesito importar. Copiar carga, no lo hagas mal. Y ahora deberíamos tener este tipo de memorización, es bastante simple, en realidad.

Y con eso, llamándolo de nuevo, nunca ejecutas una función dos veces, por lo que los headers solo se llaman una vez, y si copias algo de nuevo no está leyendo el header de nuevo y ves que no está invocando copy graph de la tarea varias veces. Así que optimizamos eso, y necesitamos lo mismo más tarde para nuestros bits incrementales.

Así que el siguiente paso. Así que el siguiente paso es añadir algún tipo de sistema de ejecución incremental. Así que lo que no queremos hacer es algo como simplemente iniciar main de nuevo y buscar todo en la caché, porque eso es lo que hemos hecho con Webpack, y la sobrecarga de buscar todo en la caché es real y es un problema. Así que lo que queremos hacer es adoptar un nuevo enfoque, y el enfoque es similar, hacerlo de la manera opuesta, por lo que no llamar funciones de arriba a abajo. En realidad queremos ir de abajo hacia arriba, así que queremos obtener, como, desde el archivo cambiado, averiguar qué funciones están afectadas y volver a calcularlas. Así que queremos ir desde los archivos cambiados, así que desde las lecturas de archivos, e invalidar eso y luego hacer burbujear todo el sistema para ponerlo en el estado correcto de nuevo.

Así que para hacer eso, en realidad necesitamos algún tipo de gráfico para almacenar qué tareas están conectadas a otras tareas. Así que queremos saber que cuando invalidamos, como, un recall, que tenemos que invalidar nuestro método de copia o algo así. Así que lo que queremos hacer es almacenar algo, como una tarea dependiente, y tal vez un conjunto lo haría. Así que almacenar una lista de tareas de las que depende esta tarea. Que depende de esa tarea. Y queremos llenar esto para que realmente establezcamos la tarea, tarea dependiente, en la tarea actual. Así que el problema es que no conocemos la tarea actual. Así que lo que queremos hacer, y puede que no haya una tarea actual para la aplicación principal, añadir como solo si tenemos una tarea actual, la añadimos a la tarea dependiente. Y luego queremos rastrear cuál es la tarea actual. Así que eso en realidad no es súper complicado. Podemos tener como una variable que también es una tarea actual, y luego tener una función, envolver nuestras llamadas con algún tipo de estado donde tenemos esta tarea actual. Así que tenemos este tipo de método de tarea actual. Tarea actual, donde llamas a una función con esta tarea actual establecida en algo. Tal vez Copilot pueda hacer eso. Sí, puede hacerlo. Así que lo que queremos hacer es, como, simplemente establecerlo antes de la función y restaurarlo al valor antiguo después. Y luego usamos esta nueva función para envolver nuestra llamada en esta tarea actual. Así que ahora hacemos una ejecución que estamos dentro de esa tarea y podemos rastrearla en todos sus hijos. Así que ahora tenemos este tipo de árbol de ejecuciones, que vemos en la salida almacenada en nuestra estructura de tareas. Así que ¿cómo usamos eso? Así que queremos hacer este tipo de invalidación y luego hacer burbujear a la tarea dependiente. Así que queremos tener algún tipo de función que se llame Invalidate, que invalida una tarea y la calculamos y también invalida, como, la tarea dependiente. Primero, quieres registrar eso porque es, como, agradable ver lo que está sucediendo.

Eso es solo para, como, imprimir lo que está sucediendo para que puedas verlo. Y necesitamos almacenar los nombres. Así que tenemos que almacenar algunas cosas, como nombre, función y argumentos. Para que podamos acceder a ello haciendo invalidación.

Y luego, el primer paso es recalcular la tarea. Y el segundo paso es invalidar la dependencia. Sabes, Copyload ya sabe lo que queremos hacer. Bien. Así que lo que queremos hacer es simplemente ejecutar la tarea de nuevo haciendo eso. En realidad, no es correcto. Así que queremos ejecutar la tarea de nuevo y almacenar el nuevo resultado. Así que queremos envolverlo con la tarea actual de nuevo, pero luego solo invocar la función de tarea con nuestros argumentos de tarea. Así que lo calculamos, pero después de recalcular las tareas, el resultado podría cambiar o probablemente ha cambiado, con suerte. Y luego queremos recorrer todas las tareas dependientes e invalidarlas también para que puedan recalcularse también. Así que si tenemos una tarea dependiente, queremos iterar sobre ellas e invalidarlas. Y esto no se llama en ningún lugar, así que queremos llamarlo, por ejemplo, desde un watcher. Así que añadimos algún tipo de función a este tipo de cosa que es getInvalidator, addInvalidator, que devuelve la función de invalidación para la tarea actual. Así que si no tienes una tarea actual, entonces queremos lanzar, pero al final, queremos devolver una función que te permita invalidar la tarea actual. Y esta función se puede usar en nuestra implementación del sistema de archivos, que actualmente se ve como eso. Así que si eliminas algo, llamamos a read file. Si escribes algo, llamamos a write file. Sí, es bastante simple.

Entonces, ¿cómo hacemos uso de nuestro tipo de sistema de invalidación? Así que podemos obtener el invalidador en este tipo de función. Ahora, tenemos eso, pero ¿cuándo lo llamamos? Así que necesitamos tener algún tipo de watcher. Afortunadamente, hay una implementación de watcher en Node.js. Y para simplificar, solo observamos todo el directorio de forma recursiva. Y en algunos casos extremos no hay sistema de archivos debido a Node.js. Así que ahora queremos invalidar todas las llamadas de lectura que se ven afectadas por este tipo de archivo que ha cambiado. Así que lo que queremos hacer es almacenar nuestro invalidador en algún lugar. Así que tenemos algún tipo de lista de invalidadores.

Y luego almacena el invalidator. En el conjunto de validadores. Almacénalo en este tipo de mat. Así tenemos acceso a todos los invalidadores de todas las llamadas de lectura, por lo que podemos simplemente llamarlos. Y eso es lo que realmente queremos hacer. Así que obtenemos el invalidator. De los invalidadores, a través del sistema de archivos. En realidad eso está mal. Porque el sistema de archivos es relativo y equipo humano. Así que hazlo absoluto. Y obténlo de la lista. Y si lo tenemos, si tenemos un invalidator, podemos llamarlo.

Pero eso lleva a que, como, porque un archivo cambió, es como, atributos cambiados, archivo agregado, múltiples sistemas. Eventualmente lo activaría múltiples veces. Así que queremos hacer un debounce un poco para que sea legible en la salida. Establecer timeout. Y llamar al invalidator. Tal vez hacerlo 100 milisegundos. Y sí. También queremos bloquear algo. Así que tal vez hacer algo como archivo cambiado. Así que realmente ver qué está pasando. Sí. Ups. Genial. Más o menos funciona pero hay un error.

Así que realmente necesitamos eliminar el invalidator. Así que elimínalo. Porque una vez invalidado, la función invalidada múltiples veces no tiene sentido. Porque después de la invalidación, lo llamamos de nuevo y luego tenemos un nuevo invalidator que está en el mapa de nuevo.

Así que solo queremos invalidarlo una vez. Así que sí debería funcionar. Bueno, con suerte. Vamos a probarlo si me falta algo.

Bien, necesitamos importar la función getInvalidator. Así que funciona. La construcción inicial es básicamente la misma. Secuenciamos todas las cosas que pusimos antes, pero ahora básicamente no sale porque estamos observando algo. Así que técnicamente, si cambiamos el archivo, debería volver a calcular las cosas y llegar al estado de nuevo. Así que tal vez pueda simplemente guardar este archivo. Bien, invalidator. Bien, intenta de nuevo. Guardando el archivo. Oh, ahora funciona. Bien, ahora vemos que básicamente está invalidando la función de lectura y volviendo a calcular la función de lectura y luego sube por el gráfico de ejecución. Así que copy está llamando a read, así que copy también se vuelve a calcular y copy es llamado por copy graph y sube hasta la función principal. Hay algunos problemas, como que sube varias veces, como copy graph, copy graph se repite aquí porque read se usa en parse y en copy. Y también, es bastante inútil, si solo guardo el archivo, volver a calcular todo porque no cambié nada en el archivo. ¿Por qué necesitamos volver a calcular copy graph si las referencias no cambiaron en absoluto? Así que lo que queremos agregar es algún tipo de tope que podamos detener el bubbling si el resultado es el mismo. Así que el reloj está mal. Bien, tengo dos minutos, así que agrego esto. Sí, quiero invalidar solo si algo realmente ha cambiado, así que puedo agregar algún tipo de código simple para que esto funcione. Así que queremos comparar el resultado antiguo con el nuevo resultado. Así que si el resultado antiguo no es igual, no deberías hacer eso con Stringify, pero funciona por ahora. Así que solo si algo realmente ha cambiado, queremos invalidar los padres. Así que ahora intentaré esto de nuevo con la nueva implementación, y si solo guardo este archivo, ahora solo invalidó la nueva función, tal vez agreguemos algún tipo de registro. Así que si algo cambió, si el registro no cambia, perfecto. Así que si algo cambió pero no necesitamos volver a calcularlo, entonces podemos simplemente imprimir sin cambios, así que podemos detener el bubbling. Si read cambió pero nada cambió, pero si realmente cambiamos algo, como en el AST, como en un comentario, tenemos que hacer bubbling más, como read subirá, copiará el archivo de nuevo y luego analizará el archivo de nuevo, y obtendrá referencias porque las referencias del archivo no cambiaron, no tienen que volver a calcular.

En el caso de que hagamos algo como reordenar las importaciones, entonces también subimos y obtenemos las referencias y bajamos más en el árbol. Así que todo el sistema es realmente genial porque entonces podemos ir desde el evento de observación y solo invalidar ciertas partes de nuestra aplicación, independientemente de cuán grande sea la aplicación, por lo que podemos simplemente seguir el gráfico y solo volver a calcular lo necesario.

Así que intentémoslo con un ejemplo más grande. He preparado como un directorio aquí con muchos archivos, 10,000 archivos, y básicamente todos son importados desde este tipo de función. Así que lleva un tiempo compilar eso inicialmente porque tenemos que, oh espera, detente, quería desactivar el registro para eso, por eso aquí hay una fuente que imprime millones de líneas de código. Toma 10 segundos compilar eso, pero después podemos usar el mismo sistema para hacer estos cambios granulares a nuestros archivos, como, esperando a que se termine.

Así que si solo cambio este pequeño archivo aquí, entonces hará lo mismo si lo guardo, será realmente rápido en leer un archivo y verlo igual. Y si cambio el archivo de índice, es un poco más lento, porque analizar el archivo ya toma un segundo o así. Así que tenemos que agregar algo aquí, toma un poco más, pero no tiene que copiar todos los archivos, porque eso es básicamente lo mismo. Y si agrego algunos módulos más al archivo aquí, entonces volverá a calcular eso y copiará los archivos que son nuevos, y ese tipo de cosas. Hay un sistema de compilación incremental en TurboEngine, es un poco simplificado, es un poco más complicado en la práctica, pero creo que entiendes la idea de cómo puedes abordar el problema desde abajo hacia arriba, y volver a calcular solo los archivos que están afectados, y hacer que el sistema sea independiente del tamaño de la aplicación, y solo dependiendo del tamaño del cambio.

Gracias. ¡Parece que lo tengo en la mente de la gente! ¿Qué hay de integrar con otras herramientas de monorepo como NX, además de Turbo? TurboPack es integrable en cada herramienta, puedes llamarlo cosa de línea de comandos, y probablemente ofrecemos algún tipo de herramientas de integración para la caché, pero también queremos trabajar un poco más profundamente con TurboRepo, porque esa es nuestra herramienta, y nuestra idea es poder compartir las cachés entre TurboRepo y TurboPack, para que sea más integrado, pero creo que ofrecemos las mismas habilidades de integración para otras herramientas de monorepo. Creo que tiene sentido, como ir con algo con lo que estás cerca, y puedes trabajar juntos para construir este tipo de prueba de concepto. Sí, es similar a lo que hicimos con NX. Construimos TurboPack con una integración profunda con NxJS, porque ahí es donde podemos trabajar juntos y llegar a un estado donde tenemos todo lo que sabemos que se necesita para TurboPack, y luego lanzar TurboPack como una cosa independiente, para que sea usable para otras cosas también. Pero ir inicialmente con algo que conoces y puedes trabajar con un equipo es mucho más fácil de trabajar que como comunicarte con herramientas externas, y no sabes qué es necesario para la herramienta y sí. Sí, no puedes como demandar cosas de la misma manera. No puedes ser como, oye, realmente necesitamos empujar esto. Es mucho más difícil negociar eso. Sí. Muy bien, genial.

Entonces el siguiente. ¿Cómo muestras el mensaje de error en la misma línea donde se lanzó en tu IDE? ¿Qué? Sí, eso es un plugin, creo. No estoy seguro de cuál, pero uno de estos. Quien haya preguntado esto, puedes encontrar a Tobias más tarde y, ya sabes, exponer tu caso.

Así que está bien. ¿Cuándo puedo usar TurboPack de manera confiable sin... Sí. Sí. Como dije, nuestra prioridad es hacer que Next funcione, lo cual debería ser pronto. Tan pronto como el caso ya esté funcionando para muchas aplicaciones, pero descubrimos algunos casos extremos y más de las cosas modernas de Next.js. Y luego queremos... Es nuestro objetivo hacerlo una herramienta independiente porque queremos tener una herramienta similar comparada con Webpack donde puedas usarla como independiente. Pero hay muchas cosas que resolver, como cómo tomamos una configuración, cuál es la API. Y no queremos cometer los mismos errores, esta configuración como Webpack, así que queremos hacerlo más simple, más fácil de usar. Así que necesitamos pensar en eso. Y técnicamente, ahí está el independiente. Es el CLI de dos paquetes. Puedes compilarlo tú mismo en nuestro repositorio, pero no es realmente... No tiene configuración. Es solo... Tal vez no mucho todavía. No es algo que hagamos público todavía, pero planeamos hacerlo y tomará un poco. Pero vamos a llegar allí.

Sí, por supuesto. Y luego sabías que este venía. Entonces, ¿qué pasa con las aplicaciones que usan plugins de Webpack? ¿Cuál es el plan de migración? ¿Qué consejos tienes? Sí. Así que no soportaremos plugins de Webpack tal como están actualmente. Así que no es... Porque los plugins de Webpack pueden integrarse realmente profundamente en Webpack y modificar cada pequeño bit de eso. Y queremos ofrecer un sistema de plugins similar, tal vez no realmente tan profundo como los plugins de JavaScript.

Así que como la API de plugins de Rust, realmente podemos profundizar mucho en Toolpag. Pero queremos ofrecer algún tipo de sistema de plugins. Y probablemente tengas que portar tu plugin de Webpack al plugin de Toolpag. Pero eso es algo que queremos hacer. Porque la arquitectura es diferente. Simplemente no es algo que podamos hacer. Hacer que el plugin de Webpack funcione. Tal vez los simples. Pero debido a la diferente arquitectura, queremos tener algún tipo de sistema de plugins diferente. Y sí. Está bien. Sí. Tal vez también podamos importar a través de eso. Como, a través de la documentación o algo así. Sí. Sí. Tal vez podamos conseguir que Copilot lo porte.

Sí. Por supuesto. Y luego creo que probablemente nuestra pregunta final por esta vez. ¿Comparaste los tiempos de compilación con el nuevo builder de Bunn? No lo hemos comparado aún. Pero creo que el autor de Bunn lo hizo. Pero este problema. Porque actualmente solo tenemos un servidor de desarrollo. Bunn solo tiene un sistema de compilación de producción. Así que es difícil comparar actualmente. Porque nos centramos en la experiencia de compilación incremental. La experiencia de desarrollo. Y ellos se centraron en compilaciones de producción rápidas. Así que creo que eventualmente habrá una comparación. Pero probablemente no lo hagamos. Al menos no públicamente. Y tal vez ellos probablemente lo hagan. Al menos dijeron en Twitter que lo harán. Así que veamos.