Cargadores ESM: Mejorando la carga de módulos en Node.js

♪♪ Cargadores ESM, Mejorando la carga de módulos en Node.js. Hola, soy Gil Tayar. Soy bastante viejo. Volvemos a los años 80. Siempre fui un desarrollador. Hice muchas cosas, pero básicamente eso es lo que amo hacer. Otra cosa que amo hacer es usar NPM y ESM y todo eso para mejorar mi código usando modularidad extrema y código de pruebas. Actualmente soy ingeniero de software en Microsoft y trabajo en cosas interesantes como el Explorador de Datos de Azure, que es un motor de base de datos de análisis en tiempo real. Nada que ver con ESM.

Bien, aclaremos algunas cosas antes de hablar sobre cómo mejorar la carga de módulos. Hablemos de qué es ESM. ESM es el sistema estándar de módulos de JavaScript y ahora es nativo de Node.js. Así que si antes teníamos common.js module.export para exportar algo y require para importarlo, en ESM, usas la sintaxis estándar export e import para hacer la exportación e importación de módulos. La sintaxis nativa funciona en Node.js, la mayoría de las personas todavía usan common.js pero ESModule se está utilizando cada vez más.

¿Qué es la carga de módulos en Node.js? Hablemos un poco sobre esa carga de módulos. En primer lugar, ¿qué es un módulo? Un módulo es básicamente un archivo glorificado, simplemente se llama módulo. Así que cuando ejecuto un módulo o importo un módulo, básicamente estoy ejecutando el código dentro del módulo, es una carga de módulo de ejecución glorificada. Así que incluso cuando estoy importando module.js en la parte superior, está ejecutando module.js en la parte inferior y luego continúa ejecutando main.js. Todo se trata de ejecución glorificada. En primer lugar, una nota para los usuarios de TypeScript, si estás usando TypeScript en Node.js, estás usando la sintaxis de importación-exportación pero probablemente estás transpilando eso a common.js porque ESM es bastante nuevo en el juego. Así que TypeScript generalmente, por defecto, transpila a common.js. Así que si estás probando todas las cosas que estoy haciendo aquí con los cargadores ASM en tu código de TypeScript, no funcionará. Tienes que no traducir el ESM usando module.node.next. Y tienes un ejemplo en el repositorio de GitHub, no te preocupes, al final, tendrás un enlace al repositorio de GitHub con un bonito código QR y un enlace a esta presentación. Vale. ¿Cuáles son las fases de la ejecución del módulo? ¿Cómo ejecuta Node.js un módulo? No es simple. En primer lugar, resolvemos la URL. Así que si estamos haciendo import.slash module.js, tenemos que resolverlo a la ruta absoluta en el disco. Y ESM no habla de rutas.

Habla de URLs. Usualmente las URLs son URLs de archivo, pero son URLs de todos modos. Una vez que resuelven la URL, una vez que Node.js resuelve la URL, lee el archivo desde el disco. Y esto es diferente de CommonJS, pero no hablemos de qué, carga recursivamente todos los modules en el archivo sin ejecutarlos.

Observa que no hemos ejecutado el módulo ESM de arriba. Una vez que ha cargado recursivamente todos los archivos, ejecuta el código de todos los modules de abajo hacia arriba en el orden correcto. Estas son las fases de la ejecución del módulo en Node.js. Y básicamente en los navegadores también, en cualquier lugar donde se implemente ESM, estas son las fases. Y esto es diferente de CommonJS, no entramos en dónde.

Bien, hablemos de los cargadores de módulos. Los cargadores de módulos mejoran los primeros dos, mejoran, cambian y transforman cómo Node.js realiza una resolución y cómo lee el archivo, el módulo. Hablemos de mejorar la fase de resolución, daremos un ejemplo y luego daremos un ejemplo para la fase de carga.

Hablemos de la fase de resolución. Demos dos ejemplos. Uno es pnpm, es un gestor de paquetes como yarn y npm, pero pnpm cambia la forma en que se encuentran los módulos. Así que los busca en el repositorio central de caché en tu disco. Actualmente, porque no tienen cargadores, hacen varios tipos de trucos usando enlaces duros para hacerlo funcionar. Pero si tuvieran cargadores, si fuera ESM nativo, entonces podrían haber modificado la fase de resolución para buscar donde quieran. Otro ejemplo son los mapas de importación, anulando especificadores desnudos y esto es lo que intentaremos hacer. Escribamos un cargador que haga esto y entenderás lo que es en un segundo.

Ahora observa que el código de muestra es código de demostración. No lo uses en producción, no tiene manejo de errores, no maneja casos extremos, son solo ejemplos de juguete.

Bien, hablemos de anular módulos. Este es main.js y estamos importando un módulo para sobrescribir. Un módulo para anular no existe en ninguna parte en los módulos de node o en todas partes. Así que si lo ejecuto obtengo el error módulo no encontrado, obviamente. Pero digamos que tengo un archivo overrides.json que dice que un módulo para sobrescribir en realidad existe en .moduleoverride.js y este es moduleoverride.js así que hacemos console log module overridden y queremos que esto funcione. Así que queremos ejecutar el main.js con el cargador. ¿Cómo lo hacemos? Añadimos dash dash loader y apuntamos al cargador y si lo ejecutamos, boom, funciona. Esta es la sintaxis dash dash loader equals o espacio, no importa, y dot slash loader.js nota que el dot slash es importante. Si dices loader.js buscará el paquete loader.js no el archivo loader.js. Bien, así que el dot slash es esencial.

Bien, veamos loader.js no te preocupes, iremos uno por uno y lo entenderemos. Este es el cargador, es muy, muy pequeño como puedes ver escribir un cargador no es tan difícil. Primero tenemos que leer el overrides.json así que lo leemos usando top level 08 y lo analizamos para obtener el overrides.json. Perfecto, fácil, sin problemas. Ahora exportamos una función esa función tiene que llamarse resolve porque cuando NodeJS está cargando un cargador busca esa función que exportó la función y recibirá tres parámetros veremos en un segundo y es async así que puedes hacer lo que quieras allí no estás limitado a la sincronicidad. Así que hablemos de los tres parámetros. Primero el especificador el especificador del módulo es lo que está detrás de las comillas y lo siento dentro de las comillas para en nuestro ejemplo un módulo de anulación tal como aparece en el código.

El contexto que veremos más tarde tiene todo tipo de cosas pero principalmente hablaremos sobre Rex resolve si no puedes resolver algo o no quieres resolver y quieres pasarlo a Node.js puedes usar next resolve para resolver. Así que veamos el código. Si el especificador es una anulación recuerda que las anulaciones son el archivo JSON entonces si no está en las anulaciones llamamos a next resolve con un especificador. Así que si no sabemos qué hacer con él lo pasamos a Node.js. Fácil, pero si queremos saber qué hacer con él tomamos el especificador de anulaciones así que tomamos lo que sea que esté en las anulaciones y lo pasamos a Node.js. Ahora Node.js no obtendrá el especificador desnudo como el módulo para anular pero obtendrá .slash module overrides.js pero aún así lo pasamos a Node.js y boom, ahí vamos. Funciona. ¿Ves lo fácil que es escribir un cargador ASM? Realmente es así de simple. Obviamente casos extremos, manejo de errores, blah blah blah pero en esencia, esto es todo. Así que hemos visto la fase de resolución. Hablemos de la fase de carga y cómo anularla.

Así que recuerda que resolver es tomar el especificador y resolverlo a una URL completa y luego leer el archivo es donde estamos hablando de la carga. ¿De acuerdo? ¿Por qué mejorar la fase de carga? Bueno, hay muchos ejemplos. Vamos a hacer dos cosas. Cargando directamente desde HTTP en lugar de desde un archivo y cargando el código TypeScript sin construirlo. Así que podremos darle un archivo TS y simplemente funcionará. Hablemos de la carga desde HTTP. Bueno, este es el código. Así que estamos cargando desde HTTPS, ESM.SH, lo que sea. ESM.SH, y hay otros por ahí, es un servicio que te da módulos ESM de todos los nativos, todos los paquetes NPM que existen. Es realmente, realmente, realmente genial. Bueno, esto es lo que queremos ejecutar. Si lo ejecutamos así sin un cargador, obtendremos el error de esquema de URL no soportado porque Node.js nos está diciendo, No sé qué hacer con HTTPS. Perfecto. Pero si lo ejecutamos con un cargador, boom, funciona. Estamos muy, muy contentos. Veamos el cargador. Primero que nada, al igual que hay una exportación de carga. Tenemos una exportación de, al igual que tenemos una exportación de resolve para la URL de resolución. Oh espera, algo le pasó a la, estoy parando.

Sí. No, veo lo que es. Es mi, ahí vamos. Vale, era, vale. Entonces, sí. Así que ahí vamos. Este es el cargador. Como puedes ver, es simple. Lo revisaremos uno por uno como antes. Al igual que en el resolutor, el cargador tiene una función de carga que se exporta de forma asíncrona. Al igual que el ejemplo. Como el anterior.

Hablemos de la URL del módulo. La URL es la URL del módulo. Observa que esta es la URL del módulo después de la resolución. Así que los resolutores, todos los resolutores han terminado con ella. Obtenemos la URL absoluta completa. El contexto lo veremos más tarde. Y la siguiente carga, si no puedes cargar algo, puedes usar la siguiente carga para cargarlo. Suele ser el de node.js. Vale. Así que si la URL no es una URL HTTP o HTTPS, simplemente la pasamos a la siguiente carga. Muy, muy fácil. Si lo es, usamos fetch. Fetch es ahora nativo de node.js, al igual que en el navegador. Puedes usarlo sin importar nada desde el nodo V18, creo, o algo así. Así que usamos fetch para recuperar el código fuente. Seguimos las redirecciones porque esm.sh tiene redirecciones y tenemos el código fuente. ¿Qué hacemos con él? Devolvemos el resultado a node.js. El código fuente del módulo está en la fuente.

El formato es el formato del módulo. ¿Es un módulo, lo que significa ESM, common.js, JSON, WASM? En este caso, siempre decimos que si viene de HTTPS, tiene que ser un módulo. Y cortocircuito. El cortocircuito le dice a node.js, mira, no llamamos a la siguiente carga. Sabemos cuál es la fuente. Pero solo para que sepas, no llamamos a la siguiente carga y está bien. Si no añadimos cortocircuito verdadero, node.js fallará y dirá, ¿estás seguro de que no querías llamar a la siguiente carga? Si no lo hiciste, por favor envía cortocircuito verdadero, y luego añades cortocircuito verdadero, y estás bien.

¿Funcionará esto? Veamos. No. Porque esto es, quiero decir, porque el resolutor de node.js arroja un error. Así que no es el cargador el que dice, no sé qué hacer con HTTPS. Es el resolutor el que dice, no sé qué hacer con HTTPS. Esto es realmente irritante, porque ¿por qué debería importarle? ¿Por qué debería decir el resolutor, no sé qué hacer con HTTPS? Tal vez alguien más quiera saber qué hacer con HTTPS. Así que en realidad descubrí esto cuando estaba trabajando en esta masterclass, y abrí un error e implementé una solicitud de extracción. Así que en node 20, si esta solicitud de extracción pasa, no necesitaremos la siguiente fase, la siguiente cosa que soluciona esto, porque el resolutor de node.js, dice, oh, no conozco esta URL, pero está bien. Lo lanzaré en el cargador. Pero todavía tenemos este problema. Así que necesitamos un resolutor en el cargador HTTP que resuelva este problema. Tenemos que anular la resolución, también. Y esto es irritante, pero es lo que es. OK.

Aquí es donde el código se vuelve interesante. Así que por favor, por favor, por favor, presta atención. Especificadores. Recuerda, estos son especificadores. Nuestro resolutor se encontrará con tres tipos de especificadores. Especificadores de URL relativos, especificadores de URL absolutos, y lo que se llaman especificadores de osos. Y tendremos que lidiar con todos ellos, al igual que node.js. Así que los relativos son estos tipos de especificadores.

Los osos son los que están en la parte inferior. Y absoluto, sí, teóricamente, alguien puede darnos una URL absoluta. Entonces, especificadores de oso. ¿Qué hacemos? Dejamos que Node.js lo maneje. No sabemos cómo manejar los especificadores de oso. Entonces, si es un especificador de oso, entonces continuamos con el siguiente resolutor. No hay problema allí de las URL de HTTP, por lo que podemos dejar que Node.js lo maneje. Y este es un especificador de oso. Es feo. Tal vez alguien más tenga una mejor manera. Entonces diría, si el especificador comienza con un punto, entonces no es un especificador de oso. De lo contrario, analízalo. Si es una URL, si no es una URL, entonces es un especificador de oso. De lo contrario, es una URL, por lo que no es un especificador de oso. Entonces, si es un especificador de oso, pásalo a Node.js.

Ahora necesitamos tratar con URLs relativas. ¿Cómo absolutizamos una URL relativa? Tomamos la URL del módulo y la añadimos al especificador y la absolutizamos. Así que en este caso, module.js, tenemos la URL absoluta del módulo. Y la absolutizamos para obtener el module.js. Podemos hacerlo con una nueva URL en Node.js, muy fácil. Y esto es lo que hacemos. Tomamos el especificador, tomamos el context.parentURL, que es donde reside la URL padre, y obtenemos una URL al final. Y esto también se encarga de las URLs absolutas.

Ahora, si la URL comienza con HTTP, no queremos enviarla al resolutor de Node.js porque entonces lanzará un error. Así que simplemente devolvemos la URL tal cual y la cortocircuitamos. Y de lo contrario, si no es una URL HTTP, podemos pasarla al resolutor de Node.js. Esto se encarga del problema con HTTP y resolve. Y ahí lo tienen. El cargador funciona.

Hablemos de otro, la transpilación de TypeScript. El cargador anterior añadió soporte para cargar otras fuentes. Este cargador es más bien un transformador. Veamos el código de TypeScript. Este es un main.ts. Importa de otro código de TypeScript pero también importa de código JavaScript, y como pueden ver, código de TypeScript. Y este es el archivo. Nada muy interesante aquí. Ejecutándolo sin un cargador, ¿obtendremos una extensión de archivo desconocida porque no sabe qué hacer con .ts? Perfecto. Ejecutándolo con el cargador funcionará. Veamos cómo funciona un cargador de TypeScript. Si la URL termina en .ts, en primer lugar, llama a nextload. Dice, no sé cómo cargar el archivo. Lo pasaré a node.js. Node.js cargará el archivo y nos devolverá la fuente. Una vez que tenemos la fuente, podemos transformarla usando ESBuild.

Puedes usar el transpilador que quieras. Yo uso ESBuild porque es fácil. Obtienes el nuevo código y lo devuelves como este código transpilado con return source y format. Muy, muy fácil, y boom, obtienes transpilación con unas 10 líneas de código. Muy fácil.

Mira ts-node.js. Hace lo mismo, pero de manera robusta puedes ver que tiene cientos de líneas de código. Pero en esencia, está haciendo lo que mostré anteriormente.

OK. Hemos visto tres cargadores. Uno que sobrescribe modules. Hace la fase de resolución. Y dos, la fase de carga, HTTP y transpilación de TypeScript. ¿Podemos encadenar cargadores? ¿Podemos añadirlos uno tras otro? Y la respuesta es absolutamente.

Así que hagamos los cargadores HTTP y TypeScript juntos. Así que importo HTTP, pero uno de ellos es un código de TypeScript. Y quiero que los dos cargadores lo hagan funcionar. Como puedes ver, estamos usando HTTP y estamos usando TypeScript. Y estos son los modules, nada interesante aquí. Pero añadamos la sobrescritura.

OK, así que en lugar de dar la URL completa, solo daremos, ya sabes, especificadores desnudos, A y B, y especificaremos en las sobrescrituras que las URLs son URLs HTTP. Añadimos los cargadores con múltiples. Observa las comas entre ellos. También podemos usar dash-dash loader, HTTP loader, dash-dash loader, TS loader, dash-dash loader, override loader. Lo mismo. Los añadimos juntos y, boom, funciona. Veamos cómo porque esto es interesante. Observa el orden, HTTP loader, TS loader, override loader. En primer lugar, hace la resolución. La resolución obtiene un especificador y devuelve una URL, si recuerdas.

Así que noten que el cargador HTTP es el primero, pero llamará al cargador de sobrescritura. Llamará al último cargador. ¿Por qué? Porque el resolutor de sobrescritura, perdón, el resolutor de sobrescritura, cuando dice next resolve, llamará al resolutor HTTP. Y cuando el resolutor HTTP llama a next resolve, llamará al resolutor NodeJS. Así que el resolutor de sobrescritura lee el overrides.json y resuelve a través de overrides.json y lo pasa al siguiente cargador. Y este resolutor HTTP, si recuerdan, pasa los especificadores no HTTP a NodeJS y se ocupa de los especificadores HTTP por sí mismo. El resolutor NodeJS absolutizaría todo y lo pasaría, y boom, obtenemos la URL. Los cargadores, lo mismo. Llamará al último cargador, este. Este es el cargador TS que lo pasará al cargador HTTP, que pasa a NodeJS, etc. etc. El cargador HTTP buscará las URL de HTTP y pasará las URL no HTTP, y boom, funciona. Ahora, mi tiempo es corto, así que saltaré esto, pero pueden ver todo en mi presentación. Pero en realidad pueden usar cargadores con APIs, así que especifiquen un cargador que también tenga una API. Es un escenario más avanzado, no se usa mucho, pero pueden hacerlo. Bueno, resumamos. Resumamos. Los cargadores mejoran estas dos fases, no la fase de ejecución, sino la resolución de la URL, que es encontrar dónde está el módulo, y leer la URL, o lo que llamamos cargar el archivo. Bueno, los cargadores pueden ser utilizados para cargar desde diferentes fuentes, transformar el código fuente, transformar las URL resueltas, y resolver las URL de manera diferente. Muchos usos para eso. Un cargador siempre tiene al menos, bueno, no al menos. Como máximo, dos funciones de exportación, resolver y cargar. Puede tener sólo una de ellas. Una se ocupa de la resolución, que toma un especificador y lo resuelve a una URL. Puede usar el siguiente resolver en la cadena si no sabe qué hacer con algo. Y la carga toma la URL, la URL resuelta, y devuelve el código fuente, y si quiere, puede usar la siguiente carga para cargarlo. Para usar un cargador, use dash dash loader. Pueden encadenarlos, lo cual es genial, y para conmutar bien, eso es algo que pasamos. Pueden comunicarse con el cargador utilizando varios métodos. Y el futuro es brillante. Finalmente tenemos una forma formal de hacer mejoras en la carga de módulos. Ha resistido la prueba del tiempo. Todavía es experimental, por lo que aún pueden ocurrir pequeños cambios. Tengan cuidado. Es muy simple de usar, y puede ser utilizado en una gran variedad de casos de uso. Muchas gracias.