El camino hacia el soporte de importación de JSON en Node.js

Hola a todos.

Mi nombre es Anton Duhamel o aduh95 en GitHub.

Estoy aquí para hablarles sobre el camino hacia el soporte de importación de JSON en NodeJS.

Así que primero, voy a hablar un poco sobre mí, así que soy miembro del Comité Técnico de Dirección de NodeJS desde abril de 2021. Y también trabajo en Translordit, ese es mi trabajo diario. Y también me pagan para decirles que si quieren que su trabajo en NodeJS, su contribución en el núcleo de NodeJS, sea patrocinada por ellos, solo envíen un correo electrónico. Es un buen momento.

De todos modos, mi charla trata sobre los módulos JSON, ¿qué son? Así que es simplemente una forma práctica para que un autor de JavaScript interactúe con archivos JSON. Así que podría ser para configuración o para consumir una API. Y voy a repasar la historia de los módulos JSON en el ecosistema de JavaScript, y luego veré cómo podemos usarlos hoy y cuáles son los próximos pasos.

Así que la historia de los módulos JSON se remonta al comienzo de NodeJS. Así que primero, cuando se introdujo Node.js, no había un sistema de módulos, no había un sistema de módulos estándar en el ecosistema de JavaScript. Mayormente se estaban utilizando tableros de flujo. Y algo tenía que hacerse al respecto. Así que Node.js introdujo CommonJS, que también se llama CGS, y tenía soporte para JSON bastante temprano. Así que en esta captura de pantalla podemos ver que fue en 2011. Así que se puede decir que fue hace mucho tiempo en el mundo de JavaScript. Y la desventaja obvia de CommonJS o CGS es que no es compatible con los navegadores. Así que el siguiente paso es la especificación ESM o los módulos ECMAScript. Así que eso fue parte de la especificación ES6 o ES2015. Así que fue un gran salto en la especificación ES6 donde pasamos de todo JavaScript a un JavaScript más moderno. Y una de sus adiciones fue las palabras clave de importación y exportación y el mecanismo de módulo que permitiría que el código JavaScript interactúe con otros archivos JavaScript. Y eso es compatible actualmente con Node.js, navegadores, Deno, TypeScript y la mayoría del ecosistema. Y una cosa notable que debo agregar es que los navegadores en particular hacen cumplir que solo se puedan cargar archivos JavaScript a través de este mecanismo. Y eso será importante más adelante. En el lado de Node.js, la primera implementación se lanzó en la versión 8.5.0. Estaba en una etapa muy experimental en este punto y imitaba la mayoría de los mecanismos de CommonJS. Así que una de sus características era poder importar archivos JSON también. Así que cuando se lanzó eso, ha habido discusiones para agregar el soporte de módulos JSON en los navegadores. Y eso se fusionó en 2019.

Entonces, la idea era si, en un navegador, se cargaban módulos a través de HTTP. Si la respuesta HTTP contiene un tipo MIME para un archivo JSON, se cargaría y analizaría como un archivo JSON. Si es JavaScript, se analizaría y cargaría como JavaScript. Pero eso fue revertido unos meses después debido a preocupaciones de seguridad planteadas por algunos de los implementadores. Podemos profundizar en los detalles de esta reversión.

Imaginemos que estás consumiendo una API del clima y esperas obtener un objeto JSON con un valor diferente en su interior. Lo importas como un módulo porque puedes hacerlo. ¿Y qué sucede si en lugar de devolver un archivo JSON, el servidor, ya sea porque está comprometido o porque es malicioso, devuelve un archivo JavaScript que hace algo malicioso? En este ejemplo, estoy agregando una llamada fetch que enviaría todos los datos del almacenamiento local a otro servidor. Pero podría ser cualquier cosa, es un comportamiento indefinido en este punto. Y los proveedores de navegadores decidieron que eso no era aceptable.

Para solucionar esto, se planteó una propuesta para cambiar el lenguaje JavaScript y agregar una adición a la sintaxis de importación que pudiera evitar que esto suceda. Como puedes ver aquí al final de esta declaración de importación, hay una afirmación con tipo JSON, lo que significa que si la respuesta no es un dato JSON, la declaración de importación falla y el código no se ejecuta. Si no estás familiarizado con cómo cambiar el lenguaje JavaScript, sería interesante hablar un poco al respecto. El lenguaje JavaScript está gobernado por la especificación ECMAScript y esa especificación está escrita por el comité TC39. El TC39 tiene una lista de propuestas que está disponible públicamente y cada propuesta pasa por cuatro etapas diferentes. Los módulos JSON y la propuesta de afirmaciones de importación se encuentran en la etapa tres, lo que significa que está casi terminada y está lista para ser implementada. Están esperando comentarios antes de decidir si pasará a la etapa cuatro, que es cuando la propuesta se integra en la especificación oficial. También quería mencionar la propuesta de plantillas, si no estás familiarizado. Estoy muy emocionado por esta. Es una API para reemplazar la API de fecha actual en JavaScript, que se supone que es mejor que la API actual. De todos modos, solo quería mencionarlo. Volviendo a los módulos.

Entonces, ahora que la especificación ECMAScript tiene un mecanismo para garantizar que no haya problemas de seguridad al cargar módulos JSON. Esto se remonta a la especificación HTML, que ha realizado una actualización de la especificación para permitir módulos JSON cuando se presenta una afirmación. Y ahora es el momento de que NetJS se base en ambas especificaciones para tener sus propios módulos JSON.

Entonces, es posible que te preguntes en este punto qué tiene que ver la especificación HTML con la implementación de NetJS. Tengo un ejemplo para ti. En este caso, cuando el usuario importa dos veces el mismo módulo, pero con un tipo de afirmación diferente. Curiosamente, la especificación HTML no define qué debería suceder en ese caso. Nos prohíbe resolver ambos. Dice que al menos uno puede resolverse, como máximo, el otro debe ser rechazado. Y deja a los implementadores cómo lidiar con eso. Entonces, en el caso de NetJS, decidimos que tiene sentido seguir la definición de la especificación HTML sobre cómo manejar esto. De esta manera, podemos asegurarnos de que un módulo se pueda ejecutar exactamente de la misma manera en el navegador o en NetJS. Por lo tanto, cuando trabajas en NetJS, a veces tienes que consultar la especificación HTML para asegurarte de que la implementación sea a prueba de futuro. A prueba de futuro. Cuando NetJS implemente las importaciones HTTPS, funcionará como en el navegador. ¿Cuál es el estado actual? Actualmente, NetJS tiene disponible la afirmación de importación y los módulos JSON en la versión 17, y la versión 16 también llegará pronto. TypeScript también en la versión 4.5, Deno en la versión 1.17, los navegadores Chromium también los han agregado. Aún falta en Firefox, Safari y Vendors, pero esperamos que eso se solucione pronto. ¿Cómo usarlos? Es posible que ya hayas visto algunos ejemplos en mi charla, pero quería dar una visión general clara. Los importas como cualquier otro módulo y agregas la afirmación al final.

Sí, ¿y ahora qué? Entonces, la pelota está ahora en tu tejado, así que si eres un jugador de JavaScript, puedes probarlo, jugar con él. No recomendaría ponerlo en producción por ahora. Tal vez quieras esperar a que alcance la etapa cuatro antes de hacerlo, pero sí, definitivamente, si tienes un proyecto de prueba, con el que quisieras experimentar, definitivamente hazlo. Puedes abrir problemas y solicitudes de extracción en los repositorios y participar en la discusión sobre cuál es el siguiente paso. Entonces, Node.js ahora ha implementado la misma característica de compatibilidad web. ¿Queremos ir más allá de eso? Entonces, tal vez, sí, más módulos, módulos de Tomo, TypeScript, ¿por qué no Coffeescript? Definitivamente, son cosas a las que nos gustaría agregar soporte en Node Core. Necesitamos a algunas personas que tengan la voluntad de hacerlo realidad. Así que si eres tú, ya sabes. Sí, eso es todo por mi parte. Así que gracias por sintonizar y si tienes alguna pregunta, este es el momento.

¡Hola, Ardaeen! Gracias por una charla tan completa. Hicimos la pregunta que hiciste a nuestra audiencia y aquí están los resultados. Bueno, la mayoría, un 73%, dice que lo usan, pero se transpila a CommonJS usando TypeScript, Mabel, etc. Interesante. Sí, supongo que hay muchos amantes de TypeScript en la audiencia hoy. Aún así, es bueno ver que al menos uno de cada cinco lo usa sin traducción. Así que eso es genial. Y todos han oído hablar de ello al menos. Sí, quiero decir, 0%, no sé qué es. Al menos me gustó esta parte de la investigación. Sí, habría sido aterrador descubrir que no saben nada al respecto. Entonces, ¿qué esperas, algo diferente o qué te sorprendió aquí? Todavía me sorprende un poco que tanta gente transpile a CommonJS, pero supongo que tiene sentido porque es la forma clásica de hacer las cosas.

Entonces, si tienes un proyecto que tiene un poco de historia y ha estado en su lugar durante un tiempo, tal vez ESM no estuviera disponible y estuvieras usando CommonJS, puede tener sentido. Sí, sigue siendo interesante verlo.

Sí, de acuerdo. Entonces, respondamos algunas preguntas de la audiencia. Tenemos una pregunta en la diapositiva número 18, mencionaste que no es posible importar una versión de un JSON en una sola línea, pero funciona en dos líneas. ¿Cuáles son las diferencias entre las dos sintaxis? Sí, es un poco complicado si no estás acostumbrado a la sintaxis ESM. Cuando trabajas con archivos JSON con llamadas requeridas, puedes hacerlo en una sola línea, importar una parte, un fragmento del archivo JSON. Y eso no funciona en la sintaxis ESM, principalmente por razones de rendimiento. Cuando el motor de JavaScript lee tu importación, tiene que saber si lo que estás importando realmente existe. Y sería demasiado costoso para él leer el archivo JSON en esta etapa. Por eso está prohibido. Y puede parecer arbitrario si no estás acostumbrado a ello. Pero sí, es algo que debes tener en cuenta. Pero sí, obtén todo y luego obtén la versión de eso. Entonces, sí.

Tenemos otra pregunta. ¿Crees que con TC39 adoptando tipos como comentarios y ESM nativo mediante la agrupación con el tiempo, ESM ganará más usuarios? Sí, es difícil predecir cómo el ecosistema de JavaScript se adaptará a esas cosas. Ciertamente espero que suceda porque creo que ESM es realmente increíble y es el futuro de JavaScript. Y ciertamente ayudar a reducir la brecha entre lo que los usuarios quieren escribir como código debería ayudar. Entonces, sí, me gustaría responder sí a la pregunta, pero dependerá de todos los demás, ya sabes. Sí, siempre es complicado. Sí, diría que puede ir en cualquier dirección. Pero sí, veamos qué depara el futuro para eso.

Tenemos otra pregunta de Uswal. Algunas personas han planteado algunas preocupaciones con ESM. Por ejemplo, su incapacidad para hacer cosas como const, inicializar un módulo igual a require, luego el nombre del módulo y luego llamarlo con algunas opciones. ¿Qué crees que es una forma adecuada de superar esto? Sí, es un poco como la primera pregunta. Usar la sintaxis ESM a veces te obliga a usar dos líneas en lugar de lo que podría haber sido una sola en CommonJS.

Y sí, no creo que realmente haya una solución alternativa para eso. Y a algunas personas realmente les gusta más una sintaxis que la otra. Eso es seguro. Pero sí, tal vez si no estás acostumbrado a ESM y aún quieres usar CommonJS. Por cierto, todavía es posible. No creo que desaparezca pronto, pero si quieres usar ESM, recupera esas capacidades. Sí, supongo que no hay una buena respuesta para eso. Tienes que trabajar en torno a la sintaxis.

Entonces, como dije, mayormente se elige por razones de rendimiento. El rendimiento no importa tanto en CommonJS porque solo funciona en Node.js, que no realiza una llamada de red mientras que ESM funciona en todas partes. Entonces, si tienes que hacer una llamada de red cada vez que importas algo, puede acumularse bastante. Por lo tanto, el rendimiento fue más descuidado al diseñar esta sintaxis. ¿Y cuál era la pregunta exactamente? ¿Hay alguna forma de superar esto? Sí, para superarlo, no creo. Entonces sí, supongo que la respuesta es que no creo que se pueda superar. Es solo un cambio de perspectiva en cómo importas tus APIs y cómo las exportas también. Bueno, necesitas encontrar una solución y superarlo. Entonces se nos preguntó qué sucede si importas un JSON no válido y si se puede cachear ese error. Entonces, si importas, hay dos tipos de importaciones cuando usas la sintaxis ESM, las importaciones estáticas. Esa es la que ves a nivel superior, importar nombre desde la URL o el nombre del módulo. Entonces, si intentas importar un archivo JSON que es inválido de esta manera, todo el gráfico del módulo se bloqueará. Entonces, si en alguna parte de tus importaciones estáticas tienes una importación de JSON no válida, se bloqueará y no puedes capturar eso, ¿de acuerdo? Eso es algo de lo que debes ser consciente, tal vez algo que quieras, tal vez algo que no quieras, y si no lo quieres, puedes usar en su lugar importaciones dinámicas. Esa es la otra importación con los paréntesis y colocas el nombre de tu módulo, y devuelve una promesa y puedes capturar el error, si hay un error, solo agrega un .catch o si esperas, puedes tenerlo en un try catch y se parece a una llamada de require. De acuerdo, sí. Entonces, bueno, tenemos otra pregunta, ¿NodeJS agregará soporte para módulos CSS? Supongo que depende si hay un buen caso de uso para eso y si alguien se encarga de llevarlos, no creo que sea realmente una característica de enfoque más amplio porque no creo que haya muchas razones para tener módulos CSS en NodeJS hoy en día, pero si tienes un caso de uso, puedes hacer que suceda si tienes suficiente voluntad. Sí, entonces puedes plantear un problema o un hilo de discusión en el repositorio de GitHub para eso, tal vez. Sí, definitivamente hazte conocer porque si nadie dice que no lo necesitamos, nadie querrá implementarlo. Sí. Genial, muchas gracias. Esas fueron todas las preguntas que teníamos. Así que muchas gracias por responder. Y para la audiencia, aún pueden hacer preguntas a Antoine. Solo vayan a su sala de conferencias. Pueden ir a la línea de tiempo y ver dónde está su sala de conferencias, únanse a él y hagan más preguntas o discutan si quieren discutir algo. Muchas gracias Antoine una vez más por unirte a nosotros. Fue realmente genial tenerte aquí. Sí, gracias y bienvenido. Y gracias por tenerme.