Compatibilidad con Node.js en Deno

¡Hola, amigos! Mi nombre es Bartek y soy miembro del equipo principal de Deno. Hoy vamos a hablar sobre la compatibilidad de Node.js en Deno. En esta charla, me gustaría darles una breve descripción de qué es Deno, y tratar de responder algunas preguntas sobre la compatibilidad con Node.

Entonces, ¿puede Deno ejecutar aplicaciones y bibliotecas ofrecidas para Node.js? ¿Cuáles son los compromisos? ¿Cómo funciona todo y qué sigue en nuestro plan? ¡Así que empecemos!

Deno uno a uno. Deno es una nueva runtime de línea de comandos para JavaScript y para TypeScript. Es similar a Node.js, que puedes ejecutar tu código JavaScript, pero la diferencia es que también admitimos TypeScript como ciudadano de primera clase. Una palabra de precaución aquí, Deno en realidad no ejecuta tu TypeScript. Solo lo transpila a JavaScript por debajo, detrás de escena, por lo que no necesitas configurar una cadena de compilación ni nada por el estilo. Deno también tiene como objetivo ser divertido y productivo. Nos gusta pensar en ello como una bolsa de bloques de LEGO.

Deno es un archivo ejecutable único. Este archivo es todo lo que necesitas para ejecutar cualquier programa de Deno, y siempre distribuiremos Deno de esta manera. Deno funciona en Linux, funciona en Mac y en Windows, así que dondequiera que vayas, un nuevo servidor, un nuevo portátil, lo que sea, solo necesitas ejecutar un comando para obtener Deno y estar listo para comenzar.

Deno tiene algo que nos gusta llamar ejecución segura por defecto. Lo que significa es que ninguno de tus programas puede acceder a tu sistema de archivos, tus variables de entorno, procesos patrocinadores, o incluso abrir una conexión a internet a menos que lo permitas explícitamente. En este breve ejemplo también podemos ver que puedes enlazar directamente a código de terceros y ejecutarlo incluso si no confías en este código. Así que aquí estamos ejecutando un ejemplo de DenoSTD, que es la biblioteca estándar de Deno, es un conjunto de módulos que están garantizados para funcionar con Deno, pero podría haber sido cualquier URL en el mundo que puedas imaginar, y en este caso, donde no se proporcionan banderas además de los subcomandos de ejecución, este programa no puede hacer nada en tu computadora. Pero si quieres acceder a un sistema de archivos o generar un subproceso o abrir una conexión a internet, puedes darle a Deno algunas banderas y decirle que permita que tu programa realmente haga estas cosas. Y como puedes ver aquí, algunas de estas banderas te permiten limitar aún más esto. Por ejemplo, podemos permitir que nuestro programa lea desde el sistema de archivos, pero solo desde el directorio slash tmp. O podemos decirle a tu programa que permita abrir una conexión a internet, pero solo limitada al dominio google.com.

Deno te permite enlazar cualquier código de terceros utilizando URLs. Funciona de la misma manera que en el navegador. En este ejemplo podemos ver nuestra importación de módulo ES. Estamos importando una función magenta, nuevamente de Deno STD. Esta vez lo estamos haciendo desde el módulo fmt slash colors. Por lo tanto, esta resolución de módulo es simple y compatible con los navegadores y Deno no tiene noción de módulos de node o indexJS. O en realidad, de eso se trata esta charla después de todo. Deno no depende de un servidor centralizado. Es decir, no estás explícitamente vinculado solo a npm si quieres enlazar tus paquetes o instalar nuevos paquetes o un registro privado si tienes uno. Puedes obtener código desde cualquier lugar en internet, ya sea servidores públicos o servidores privados si proporcionas cabeceras de autorización adecuadas. Deno como un runtime recupera, almacena en caché y compila este código, o lo transpila, de forma transparente en la primera ejecución. Después de la primera ejecución, el código ya está en caché, por lo que no es necesario descargarlo nuevamente. De hecho, Deno no volverá a descargar el código a menos que se lo pidas explícitamente.

Entonces, ¿por qué estamos pensando o trabajando en la compatibilidad con Node.js? Bueno, npm es posiblemente el ecosistema de paquetes más grande del mundo, y los usuarios simplemente quieren usar este ecosistema de paquetes. Cuando Deno salió por primera vez con la versión 1.0, afirmamos explícitamente que no somos compatibles con npm. Y eso estaba bien. Aquí, algunos usuarios todavía encuentran la falta de soporte para npm como un gran obstáculo para su adopción. Entonces, algunos usuarios quieren probar Deno en lugar de Node.js. Sin embargo, el costo de cambiar de un runtime a otro a menudo resulta demasiado alto para siquiera intentarlo.

Entonces, al proporcionar compatibilidad con Node.js, queremos facilitar y suavizar el proceso de migración para los usuarios. Intentemos responder a esta pregunta. ¿Puede Deno realmente ejecutar aplicaciones, bibliotecas o paquetes que fueron escritos para Node.js? Y sí, pero... Y antes de llegar a este pero, las imágenes hablan más que mil palabras.

Así que voy a darte un ejemplo rápido, o en realidad dos ejemplos de código ofrecido para Node.js que ya se está ejecutando en Deno. En el primer ejemplo, podemos ver la herramienta muy popular llamada ESlint que se está ejecutando directamente en Deno. Así que obtuvimos las fuentes de ESlint. Por el bien de este ejemplo, digamos que ya usamos npm. Y ahora estamos ejecutando este código usando Deno. Lo importante a tener en cuenta aquí es que estamos proporcionando esta bandera "compat", que le indica a Deno que realmente proporcione esta compatibilidad con Node.js. Y luego pasamos "unstable", que actualmente es necesario debido a algunas limitaciones en la API. Por lo tanto, algunas de las APIs aún no están definidas y pueden cambiar en el futuro. Y esta bandera transmite el mensaje de que, sabes, esto es inestable, así que algo podría cambiar, pero no te preocupes, estará bien.

El segundo ejemplo es en realidad npm en sí mismo. Ya podemos ejecutar npm en Deno y usarlo para instalar otros paquetes. Una cosa que puedes notar aquí es que hay algunas indicaciones que dicen "no implementado". Por ejemplo, process.onCodeException o process.onUnhandledRejection. Llegaremos a eso en un momento. Entonces sí, Deno puede ejecutar aplicaciones, bibliotecas y paquetes ofrecidos para Node.js. Sin embargo, aún no se admiten todos ellos. Estamos enfocando nuestros esfuerzos en permitir a los usuarios ejecutar los paquetes y herramientas más populares en este momento. Ya vimos ESLint y npm, pero también estamos haciendo grandes avances para hacer que Yarn funcione, Vite, Next.js, que probablemente sea el framework más popular en este momento, y Mocha, que también es uno de los frameworks de testing más populares en este momento. Entonces sí, Deno puede ejecutar código ofrecido para Node.js, pero no todo.

La razón es que todavía estamos trabajando en la adaptación o provisión de polyfills para algunos de los módulos integrados de Node.js, como TLS o ChildProcess. Se está trabajando en ellos, sin embargo, su API es muy extensa, por lo que puedes crear subprocesos tal como lo harías en Node con Deno, sin embargo, no todas las APIs funcionarán en el momento. Otra cosa importante es la integración de CJS y ESM. Deno desde el primer día fue ESM primero. Y no entendían los módulos de CommonJS. Sin embargo, debido a que mucho código ofrecido para Node.js todavía utiliza CommonJS, es crucial proporcionar esta integración o interoperabilidad entre los dos formatos. Y por cierto, esto es algo que Node.js ya admite de forma nativa, así que solo estamos tratando de ponernos al día.

Aunque estamos ejecutando código ofrecido para Node.js, este código aún está sujeto a las mismas reglas de permisos o banderas de allow que vimos al principio de la presentación. Eso significa que puedes ejecutar código ofrecido para Node.js en Deno y obtener un beneficio adicional de poder aislar tus programas en ciertos directorios o dominios de Internet o evitar que generen subprocesos.

Entonces, ¿cuáles son las compensaciones de esta compatibilidad? Bueno, algunas APIs que existen en Node.js y en Deno y en navegadores, simplemente no son compatibles. Un buen ejemplo es setTimeout. Esta es una API global. Está disponible en Node.js, está disponible en navegadores, está disponible en Deno. En Node.js, también puedes importarlo desde el módulo Timers. Sin embargo, la diferencia es que en Node.js, cuando llamas a setTimeout, obtendrás una instancia de la clase TimeoutClass. Sin embargo, en navegadores y en Deno, obtendrás un número, que es un identificador para este Timeout. En Node.js, debido a este tipo de retorno, muchos paquetes dependen de él para, por ejemplo, cancelar el temporizador. Es decir, decirle a Node.js que si este Timeout es lo último que se ejecuta o no esperas nada más, simplemente no esperes a este Timeout y terminemos de ejecutar ahora mismo. De manera similar, en navegadores y en Deno, hay mucho código que depende del hecho de que es posible que desees hacer una comprobación de tipo basada en este valor de retorno. Hay mucho código que hace typeof ID igual a número. Este es un problema realmente difícil. Llevamos tres meses pensando en ello. Si alguien del equipo técnico de Node está escuchando esta charla, por favor comuníquense y veamos cómo podemos avanzar para que esto sea más compatible entre los entornos.

Otra compensación es que la experiencia del desarrollador no es tan buena. Pero en este momento, estamos trabajando en ello, estamos progresando y estamos pensando en cómo hacer que esto sea más agradable para que los usuarios cambien entre Node.js y Deno de manera transparente. ¿Y por qué esta DX no es tan buena? Entonces, necesitas pasar muchas banderas a Deno para decirle que se comporte como Node.js. Necesitas pasar ____ compat. Esta bandera configura variables globales como process. Process es una variable global que está disponible en el entorno de Node.js. Sin embargo, no está disponible en Deno de forma predeterminada. Pero si pasas esta ____ compat, le dirá a Deno que prepare esta variable global para ti. Necesitas pasar ____ hands table. Una vez más, algunas de las APIs aún no están completas y pasarán por algunos cambios o un proceso de evaluación. Esto es solo para señalar a los usuarios que, sabes, puede haber algunos problemas aquí y allá, pero está bien. Nos estamos moviendo rápido. La mayoría de las veces, también necesitas pasar ____ allow read, y esto es necesario para los módulos CJS, para CommonJS, porque la resolución de CommonJS depende en gran medida de sondear el sistema de archivos y los directorios de módulos de Node. Y dado que está implementado al 100% en el espacio de usuario en este momento, está sujeto a comprobaciones de permisos de Deno.

Otra compensación es que algunas APIs podrían no ser compatibles en el futuro. Por lo tanto, un módulo Inspector o un módulo V8 podrían no llegar a Deno en absoluto. Todavía estamos discutiendo esto. Es tanto un problema técnico como, de hecho, si queremos admitir estas APIs, es porque consideramos que algunas de ellas son cuestionables.

Una advertencia bastante importante es que los complementos nativos no serán compatibles. Los complementos nativos en Node.js dependen de Node.JPG y básicamente son escritos en C++, mientras que Deno está escrito en Rust. Por lo tanto, no es tan fácil conciliar este problema debido a la estabilidad de la ABI. Sin embargo, podría tener una buena respuesta a este problema en las próximas diapositivas.

Entonces, antes de llegar a eso, hablemos brevemente de cómo funciona todo. Es posible que te sorprenda, pero la mayoría de estas APIs provenientes de Node.js se polyfillan en el espacio de usuario. Una vez más, voy a referirme a este proyecto llamado DinoSTD, que es una biblioteca estándar que enviamos con Dino. Es una colección de módulos ofrecidos en TypeScript que están garantizados para funcionar con Dino. Y allí tenemos este módulo Node, y este módulo Node contiene muchos archivos que básicamente polyfillan todas las APIs disponibles en varios módulos integrados de Node.js. Te animo a que vayas a este enlace y lo compruebes por ti mismo. Puede resultarte muy educativo.

Un problema con esto es que el código del tiempo de ejecución que proporciona los módulos integrados y Node.js se ofrece como módulos CommonJS, mientras que todo este código en DinoSTD es en realidad módulos ES. Por lo tanto, no solo tuvimos que reescribir la mayor parte del código a TypeScript y hacerlo seguro en cuanto a tipos, sino que también tuvimos que hacer una reorganización bastante significativa para que el código funcione debido a las diferentes semánticas de CommonJS y los módulos ES.

Está bien y es genial que pudiéramos hacer esto en el espacio de usuario. Sin embargo, hay algunas APIs muy intrincadas que no son realmente posibles de hacer en el espacio de usuario. Y dos ejemplos serían process.unhandledRejection, un controlador de eventos que se activa cuando hay una promesa que es rechazada pero no tiene un controlador de captura. En Deno hasta este punto, esto siempre fue un fallo grave, tu programa se cerraría. De manera similar, process.nextTick te permite programar una devolución de llamada que se llamará después del siguiente tick del bucle de eventos. Intentamos polyfillar estas APIs en el espacio de usuario. Sin embargo, debido a las estrictas semánticas de dónde deben ser llamadas o cuándo o qué debería suceder, lo cual altera cómo se comporta Deno, no pudimos hacer esto simplemente en el espacio de usuario. Por lo tanto, tuvimos que agregar soporte directo para estas APIs en el núcleo de Deno.

Entonces, ¿qué sigue para la compatibilidad con Node.js en Deno? Bueno, queremos lanzar la primera versión, la primera versión disponible públicamente de esta capa de compatibilidad en el segundo trimestre de este año. Y algunas de las cosas que nos gustaría hacer es, en primer lugar, explorar un enfoque llamado superset donde Deno básicamente admita las APIs de Node.js de forma predeterminada sin necesidad de banderas especiales o modos de ejecución diferentes a los que Deno se ejecutaría. Por lo tanto, es posible que en el futuro no sea necesario utilizar la bandera --compat. Otra idea que estamos explorando es la instalación de paquetes desde npm de forma transparente.

Es más grande que las gemas de Ruby o PyPy de Python. Y muchos usuarios nos han proporcionado comentarios de que les encantaría usar Deno, pero como no pueden utilizar bibliotecas de NPM, no es una razón tan convincente. Por eso estamos trabajando en esto. Pero para responder a la segunda parte de la pregunta, ¿deberías trabajar en código o escribir especialmente para Deno? Bueno, eso depende de ti. Pero puedo sugerirte que revises dnt, que es otro proyecto de la compañía Deno. Es una herramienta que te permite ofrecer el código para Deno primero, pero luego se configurará de forma transparente para ser publicado en NPM. Así que puedes apuntar tanto a Deno como a Node utilizando una única base de código de Deno. Y nuevamente, como estamos enviando una cadena de herramientas completa, es posible que encuentres más fácil configurar y mantener tu proyecto en lugar de depender de múltiples dependencias de NPM para el formateo, linting, etc.

De acuerdo, gracias. Sí, eso tiene mucho sentido. ¿Qué tal hacer un convertidor en lugar de hacer compatibilidad? Sí, exploramos esta opción. Sin embargo, suena más fácil de lo que realmente es. Muchos proyectos de código que están escritos para Node todavía dependen de la API basada en callbacks. Y parte de ese flujo de código, en este caso, no es tan obvio, y convertirlo automáticamente sería propenso a errores en extremo en comparación con proporcionar una compatibilidad de primera clase. En lugar de intentar hacer conversiones y luego tratar de corregir errores, lo cual probablemente tendrías que hacer por tu cuenta, parece más fácil y más seguro proporcionar estas API que ya están disponibles en Node. Y nos aseguraremos de que funcionen de la misma manera en Deno. Gracias.

¿Qué nivel crees que debería tener un desarrollador para colaborar en Deno? Lo siento, ¿puedes repetir la pregunta, por favor? ¿En qué nivel crees que debería estar un desarrollador para colaborar en Deno? Supongo que la persona está tratando de preguntar si debería ser senior o junior. No sé, tal vez eso. ¿En qué nivel para colaborar en Deno? Lo siento, ¿codificar en Deno o contribuir a Deno? Para colaborar. Colaborar, claro. Bueno, todos son bienvenidos. Tenemos decenas de repositorios diferentes y abarcan múltiples proyectos porque Deno no es una única cosa. En realidad, está compuesto por diferentes bloques que son proyectos de Rust, JavaScript o TypeScript. Así que todos pueden encontrar algo a lo que puedan contribuir, sin importar su nivel de habilidad. Si te sientes cómodo en JavaScript, tenemos proyectos que solo usan JavaScript. Si prefieres TypeScript, tenemos este gran proyecto llamado Deno STD, que es una biblioteca estándar a la que puedes contribuir y ayudarnos con la compatibilidad con Node o proporcionar un nuevo módulo. O si prefieres Rust, puedes ayudarnos con el propio Deno o alguna de las herramientas porque todas las herramientas como el formateador y el linter, etc., están escritas en Rust. Así que únete a nuestro servidor de Discord y estoy seguro de que podemos orientarte en la dirección correcta según tus intereses y tu confianza en cualquiera de estos lenguajes. No, gracias.

¿Existen herramientas para escribir pruebas robustas y amigables con los informes en Deno? Esa es una pregunta de Ivan. ¿Para probar qué, lo siento? ¿Existen herramientas para escribir pruebas robustas y amigables con los informes en Deno? Bueno, diría que lo que proporcionamos en Deno mismo, la utilidad incorporada es lo suficientemente robusta. Tenemos una API simple, una única función Deno.test que puedes usar para registrar una prueba. Y no importa si es una prueba unitaria o una prueba de integración, tenemos un montón de ayudantes como aserciones para trabajar con subprocesos.

Puedes probar cualquier cosa que desees. Y lo genial del ejecutor de pruebas de Deno es que no es mágico. Hace exactamente lo que se supone que debe hacer. Ejecuta este archivo de prueba y reporta cualquier error. No afecta el ámbito global como a veces lo hace Jest. No agrega nuevas APIs. Es exactamente lo mismo que ejecutar solo tu programa con la única diferencia de que tienes esta API Deno.test disponible para ti. Y de hecho, proporcionamos algunos ayudantes que se aseguran de que tu código no tenga fugas de memoria o que limpies después de terminar con algunos recursos como archivos del sistema de archivos o sockets de red. Así que definitivamente revisa el ejecutor de pruebas incorporado de Deno. Creo que lo encontrarás lo suficientemente robusto y lo suficientemente simple como para aprenderlo en cuestión de minutos. Gracias.