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

Bien, vamos a aclarar algunas cosas antes de hablar sobre cómo mejorar la carga de módulos. Hablemos de qué es ESM. ESM es el sistema de módulos estándar de JavaScript. y ahora es nativo de Node.js. Así que si antes teníamos module.export de common.js para exportar algo y require para importarlo, en ESM, se utiliza 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 frecuentemente.

¿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? Básicamente, es un archivo glorificado, simplemente se llama módulo. Entonces, cuando ejecuto un módulo o importo un módulo, básicamente estoy ejecutando el código dentro del módulo, es una ejecución glorificada de la carga de módulos. Incluso cuando estoy importando module.js en la parte superior, se está ejecutando module.js en la parte inferior y luego continúa ejecutando main.js. Todo se trata de una ejecución glorificada. En primer lugar, una nota para los usuarios de TypeScript, si estás utilizando TypeScript en Node.js, estás utilizando la sintaxis de import-export pero probablemente estés transpilando eso a common.js porque ESM es bastante nuevo en el juego. Por lo general, TypeScript transpila por defecto a common.js. Así que si estás probando todas las cosas que estoy haciendo aquí con los cargadores de ASM en tu código de TypeScript, no funcionará. Debes no traducir el ESM utilizando 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 código QR y un enlace a esta presentación. De acuerdo. ¿Cuáles son las fases de la ejecución de módulos? ¿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.

Se habla de URLs. Por lo general, las URLs son URLs de archivos, pero siguen siendo URLs. Una vez que se resuelve la URL, una vez que Node.js resuelve la URL, lee el archivo del disco. Y esto es diferente de CommonJS, pero no hablemos de eso, carga de forma recursiva todos los modules en el archivo sin ejecutarlos.

Observa que no hemos ejecutado el módulo ESM anterior. Una vez que carga de forma recursiva todos los archivos, ejecuta el código de todos los modules de abajo hacia arriba en el orden correcto. Estas son las fases de ejecución de módulos en Node.js. Y básicamente también en los navegadores, en cualquier lugar donde se implemente ESM, estas son las fases. Y esto es diferente de CommonJS, no entremos en detalles.

Bien, hablemos de los cargadores de módulos. Los cargadores de módulos mejoran las dos primeras, mejoran y 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. Damos 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. Por lo tanto, los busca en el repositorio de caché central en tu disco. Actualmente, debido a que no tienen cargadores, hacen varios tipos de trucos utilizando enlaces duros para que funcione. Pero si tuvieran cargadores, si fuera ESM nativo, podrían haber modificado la fase de resolución para buscar donde quisieran. Otro ejemplo son los mapas de importación, sobrescribiendo especificadores sin ruta y esto es lo que intentaremos hacer. Escribamos un cargador que haga esto y entenderás qué es en un segundo.

Ahora, ten en cuenta que el código de ejemplo 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 sobrescribir módulos. Este es main.js y estamos importando un módulo para sobrescribir. Un módulo para sobrescribir no existe en ningún lugar en los módulos de Node o en cualquier lugar. Entonces, si lo ejecuto, obtengo el error de módulo no encontrado, obviamente. Pero digamos que tengo un archivo overrides.json que dice que un módulo para sobrescribir realmente existe en .moduleoverride.js y este es moduleoverride.js así que imprimimos en la consola módulo sobrescrito y queremos que esto funcione. Entonces, queremos ejecutar main.js con el cargador. ¿Cómo lo hacemos? Agregamos guión guión cargador y apuntamos al cargador y si lo ejecutamos, boom, funciona. Esta es la sintaxis guión guión cargador igual o espacio, no importa y punto barra cargador.js ten en cuenta que el punto barra es importante. Si dices cargador.js buscará el paquete cargador.js no el archivo cargador.js. Bien, el punto barra 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. En primer lugar, tenemos que leer el overrides.json así que simplemente lo leemos usando el nivel superior 08 y lo analizamos para obtener el overrides.json. Perfecto, fácil, sin problemas. Ahora exportamos una función esa función debe llamarse resolve porque cuando NodeJS está cargando un cargador busca esa función exportada y recibirá tres parámetros lo veremos en un segundo y es asíncrona por lo que puedes hacer lo que quieras allí no estás limitado a la sincronicidad. Entonces hablemos de los tres parámetros. En primer lugar, el especificador el especificador del módulo es lo que está detrás de las comillas y lo siento dentro de las comillas en nuestro ejemplo un módulo para sobrescribir tal como aparece en el código.

El contexto que veremos más adelante tiene todo tipo de cosas pero principalmente hablaremos de Rex resolve si no puedes resolver algo o no quieres resolver y quieres pasarlo a Node.js puedes usar next resolve para resolverlo. 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 sin formato como el módulo para anular pero obtendrá .slash module overrides.js pero aún lo pasamos a Node.js y boom, ahí lo tenemos. Funciona. Mira qué fácil es escribir un cargador de ASM. Realmente es así de simple. Obviamente, casos extremos, manejo de errores, blah blah blah pero en esencia, eso es todo. Entonces 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 carga. ¿De acuerdo? Entonces, ¿por qué mejorar la fase de carga? Bueno, hay muchos ejemplos. Vamos a hacer dos cosas. Cargar directamente desde HTTP en lugar de desde un archivo y cargar código TypeScript sin compilarlo. Por lo tanto, podremos darle un archivo TS y simplemente funcionará. Hablemos de cargar desde HTTP. De acuerdo, 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 brinda módulos ESM de todos los paquetes nativos, todos los paquetes de NPM que existen. Es realmente, realmente, realmente genial. De acuerdo, esto es lo que queremos ejecutar. Si lo ejecutamos así sin un cargador, obtendremos un error de esquema de URL no compatible 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. Veámoslo, el cargador. En primer lugar, al igual que hay una exportación de carga. Tenemos una exportación, al igual que tenemos una exportación de resolución para la resolución de URL. Oh espera, algo le pasó, me detengo.

Sí. No, ya veo lo que es. Es mío, ahí vamos. De acuerdo, era, de acuerdo. Así que esto, sí. Ahí vamos. Este es el cargador. Como puedes ver, es simple. Lo repasaremos uno por uno como antes. Al igual que en el resolutor, el cargador tiene una función de carga que se exporta async. 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. Por lo tanto, los resolutores han terminado con ella. Obtenemos la URL absoluta completa. El contexto lo veremos más adelante. Y luego la carga siguiente, si no puedes cargar algo, puedes usar la carga siguiente para cargarlo. Por lo general, es la de node.js. De acuerdo. Entonces, si la URL no es una URL HTTP o HTTPS, simplemente la pasamos a la carga siguiente. Muy, muy fácil. Si lo es, usamos fetch. Fetch ahora es nativo de node.js, al igual que en el navegador. Puedes usarlo sin importar nada de node V18, creo, o algo así. Entonces usamos fetch para obtener 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 source.

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 proviene de HTTPS, debe ser un módulo. Y cortocircuito. Cortocircuito significa decirle a node.js: mira, no llamamos a la siguiente carga. Sabemos cuál es la fuente. Pero solo para que lo sepas, no llamamos a la siguiente carga y está bien. Si no agregamos 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 agregas cortocircuito verdadero, y estás bien.

Entonces, ¿esto funcionará? Veamos. No. Porque esto es, quiero decir, porque el resolutor de node.js arroja un error. Entonces 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 exasperante, en realidad, porque ¿por qué debería importarle? ¿Por qué debería el resolutor decir, no sé qué hacer con HTTPS? Tal vez alguien más quiera saber qué hacer con HTTPS. De hecho, me di cuenta de esto cuando estaba trabajando en esta charla, y abrí un error e implementé una solicitud de extracción. Entonces, en la versión 20 de node, si esta solicitud de extracción se aprueba, 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 pasaré al cargador. Pero todavía tenemos este problema. Entonces necesitamos un resolutor en el cargador HTTP que resuelva este problema. También tenemos que anular la resolución. Y esto es exasperante, pero así es como es. De acuerdo.

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 encontrará tres tipos de especificadores. Especificadores de URL relativa, especificadores de URL absoluta, y lo que se llaman especificadores de osos. Y tendremos que lidiar con todos ellos, al igual que node.js lo hace. Entonces, los relativos son estos tipos de especificadores.

Los osos son los que están en la parte inferior. Y absolutos, sí, teóricamente, alguien puede proporcionarnos una URL absoluta. Entonces, especificadores de osos. ¿Qué hacemos? Dejamos que node lo maneje. No sabemos cómo manejar los especificadores de osos. Entonces, si es un especificador de oso, continuamos con la siguiente resolución. No hay problema con las URL de HTTP, así que podemos dejar que node lo maneje. Y esto 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 lidiar con las URLs relativas. ¿Cómo convertimos en absoluto una URL relativa? Tomamos la URL del módulo y la agregamos al especificador y la convertimos en absoluta. Entonces, en este caso, module.js, tenemos la URL absoluta del módulo. Y la convertimos en absoluta para obtener module.js. Podemos hacerlo con una nueva URL en Node.js, muy fácil. Y esto es lo que hacemos. Tomamos el especificador, tomamos context.parentURL, que es donde reside la URL principal, y obtenemos una URL en el resultado. 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 listo. El cargador funciona.

Hablemos de otro, transpilando TypeScript. El cargador anterior agregó soporte para cargar otras fuentes. Este cargador es más bien un transformador. Veamos el código TypeScript. Este es un main.ts. Importa desde otro código TypeScript pero también importa desde código JavaScript, y como puedes ver, código TypeScript. Y este es el archivo. Nada muy interesante aquí. Ejecutarlo sin un cargador, ¿obtendremos una extensión de archivo desconocida porque no sabe qué hacer con .ts? Perfecto. Ejecutarlo con el cargador funcionará. Veamos cómo funciona un cargador de TypeScript. Si la URL termina con .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á el código fuente. Una vez que tenemos el código fuente, podemos transformarlo usando ESBuild.

Puedes usar cualquier transpilador que desees. Yo uso ESBuild porque es fácil. Obtén el nuevo código y devuélvelo como este código transpilado con return source y format. Muy, muy fácil, y listo, obtienes la transpilación con alrededor de 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 anula módulos. Realiza la fase de resolución. Y dos, la fase de carga, HTTP y transpilación de TypeScript. ¿Podemos encadenar cargadores? ¿Podemos agregarlos uno tras otro? Y la respuesta es absolutamente.

Entonces, hagamos los cargadores de HTTP y TypeScript juntos. Importo HTTP, pero uno de ellos es un código TypeScript. Y quiero que los dos cargadores lo hagan funcionar. Como puedes ver, estamos usando HTTP y estamos usando TypeScript. Y estos son los módulos, nada interesante aquí. Pero agreguemos la anulación.

Ok, en lugar de proporcionar la URL completa, simplemente daremos especificadores simples, A y B, y especificaremos en las anulaciones que las URLs son URLs HTTP. Agregamos los cargadores con múltiples. Observa las comas entre ellos. También podemos usar --loader, cargador HTTP, --loader, cargador TS, --loader, cargador de anulación. Lo mismo. Los agregamos juntos y, listo, funciona. Veamos cómo porque esto es interesante. Observa el orden, cargador HTTP, cargador TS, cargador de anulación. En primer lugar, realiza la resolución. La resolución recibe un especificador y devuelve una URL, si recuerdas.

Así que nota que el cargador HTTP es el primero, pero llamará al cargador de anulación. Llamará al último cargador. ¿Por qué? Porque el resolutor de anulación, perdón, resolutor de anulación, cuando dice siguiente resolución, llamará a la resolución HTTP. Y cuando la resolución HTTP llama a la siguiente resolución, llamará a la resolución de NodeJS. Entonces, el resolutor de anulación lee el archivo overrides.json y resuelve a través de overrides.json y lo pasa al siguiente cargador. Y este resolutor HTTP, si recuerdas, pasa los especificadores que no son HTTP a NodeJS y maneja los especificadores HTTP por sí mismo. El resolutor de NodeJS absolutiza todo y lo pasa, y boom, obtenemos la URL. Los cargadores, lo mismo. Llamará al último cargador, este es el cargador de TS lo pasará al cargador HTTP, que pasa a NodeJS, etc. etc. El cargador HTTP buscará las URL de HTTP y pasará las URL que no son de HTTP, y boom, funciona. Ahora, mi tiempo es corto, así que omitiré esto, pero puedes ver todo en mi presentación. Pero en realidad puedes usar cargadores con APIs, así que especifica un cargador que también tenga una API. Es un escenario más advanced , no se usa mucho, pero puedes hacerlo. Ok, 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. Ok, los cargadores se pueden usar 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, resolución y carga. Puede tener solo una de ellas. Una se encarga de la resolución, que toma un especificador y lo resuelve a una URL. Puede usar la siguiente resolución 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, usa --loader. Puedes encadenarlos, lo cual es genial, y para comunicarte bien, eso es algo que pasamos. Puedes comunicarte con el cargador usando 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. Aún es experimental, así que pueden ocurrir cambios pequeños. Ten cuidado. Es muy fácil de usar, y se puede utilizar en una gran variedad de casos de uso. Muchas gracias.