Lanzamiento de Deno 2.4

 (deno.com)
2 puntos por GN⁺ 2025-07-08 | 1 comentarios | Compartir por WhatsApp
  • deno bundle se reintroduce basado en esbuild, lo que permite crear bundles de un solo archivo para servidor y navegador, con tree shaking y optimización automáticos
  • El soporte para importación de texto/bytes y la estabilización de OpenTelemetry integrado refuerzan la observabilidad y la experiencia al usar archivos externos
  • El nuevo flag --preload, mejoras de conveniencia para dependencias con deno update, medición de cobertura de scripts, gestión de permisos y compatibilidad con APIs de Node.js reciben mejoras amplias
  • También se incluyen mejoras en LSP, Jupyter, bench/coverage y soporte para tsconfig, junto con varias mejoras de usabilidad

Resumen de los principales cambios y nuevas funciones de Deno 2.4

Regreso de deno bundle

  • En Deno 2.4 vuelve a incorporarse el subcomando deno bundle, que permite generar bundles de JavaScript de un solo archivo, ahora junto con el motor esbuild
  • Soporta tanto servidor como navegador, y también puede empaquetar sin problemas dependencias de npm y JSR
  • Ofrece un entorno más cómodo de administrar con tree shaking automático y soporte para optimización de código (minify)
  • Más adelante se planea agregar expansión programática y personalización del proceso de bundling mediante Runtime API y plugins

Soporte para importación de texto y bytes

  • Se ofrece el flag --unstable-raw-imports para poder embeber en el grafo de módulos de JavaScript archivos de datos externos como texto, binarios e imágenes
  • Antes era necesario leer archivos externos mediante entrada/salida (I/O), pero ahora se puede indicar el tipo de archivo en la sintaxis de importación para usar datos de bytes/texto directamente
  • Esta función también opera al hacer bundle o compilar, lo que facilita implementar embebido de assets en el resultado final
  • Junto con el soporte existente para importaciones como JSON y Wasm, permite gestionar varios formatos de archivo de una forma alineada con la especificación
  • Aunque la especificación aún está en discusión, Deno refleja de manera equilibrada tanto el avance funcional como la evolución del estándar

Estabilización del soporte integrado de OpenTelemetry

  • El soporte integrado de OpenTelemetry introducido en la versión 2.2 queda completamente estabilizado en la 2.4
  • Con solo configurar la variable de entorno OTEL_DENO=1, se puede automatizar la recolección de logs, métricas y trazas sin flags adicionales
  • También ofrece compatibilidad sin configuración con Node.js y soporte unificado para entornos de despliegue como Deno Deploy
  • Además, permite la vinculación/observación automática de logs de console.log y solicitudes HTTP
  • Por sus características de uso de recursos, es necesario controlar su activación mediante variables de entorno

Flag --preload para configuración previa a la ejecución

  • Se agrega el flag --preload, que permite ejecutar código por adelantado antes de correr el script principal para modificar el entorno global, cargar datos o registrar módulos dependientes, entre otros usos
  • Resulta útil para distintos escenarios de construcción de plataforma, como personalización de la plataforma o redefinición de objetos globales
  • Puede utilizarse en comandos principales como deno run, deno test y deno bench

Gestión de dependencias simplificada: deno update

  • Se introduce el subcomando deno update para actualizar automáticamente a la versión más reciente las dependencias de npm y JSR
  • Permite actualizar varias dependencias de una vez y hacer actualizaciones precisas basadas en compatibilidad Semver
  • También se ofrece como alias de deno outdated --update, mejorando la facilidad de uso

Cobertura de scripts: deno run --coverage

  • Ahora es posible recopilar cobertura no solo de cada prueba, sino de toda la ejecución, incluidos los subprocesses
  • Se puede gestionar la información de forma flexible mediante varios mecanismos, incluida la variable de entorno DENO_COVERAGE_DIR
  • El reporte HTML de cobertura ahora también incluye soporte para modo oscuro

Variable de entorno de compatibilidad DENO_COMPAT=1

  • Se introduce la variable DENO_COMPAT=1 para mejorar la conveniencia y la compatibilidad con proyectos basados en package.json y el ecosistema npm
  • Aplica automáticamente varios flags inestables (Unstable), y más adelante ampliará su soporte, por ejemplo con la omisión del npm prefix

Mejoras en gestión de permisos y seguridad

  • El flag --allow-net ahora soporta comodines de subdominios y rangos CIDR
  • Se agregan los flags --allow-import, para restringir los hosts desde los que el código puede importar, y --deny-import, para bloquearlos explícitamente
  • La API Deno.permissions ahora soporta oficialmente consultas del tipo "import"
  • Al usar Deno.execPath(), ya no se requiere permiso de lectura, lo que facilita aprovechar la ruta del ejecutable

Exports condicionales en package.json

  • Se añade soporte para exports condicionales en paquetes npm, reforzando especialmente la compatibilidad con diversos ecosistemas como configuraciones de servidor para React
  • Con flags de condición del usuario se pueden implementar comportamientos de importación personalizados y flexibles

Soporte para bare specifier en deno run

  • Ahora es posible ejecutar el punto de entrada del comando usando aliases (bare specifiers) definidos en "imports" dentro de deno.json
  • Esto brinda una gran comodidad en términos de productividad de desarrollo y automatización de gestión de módulos

Mejoras en formateo de código para formatos como XML y SVG

  • deno fmt ahora soporta el formateo automático de varios archivos de plantilla como .xml, .svg y .mustache

Soporte reforzado para tsconfig.json

  • Mejora la precisión al reconocer varias opciones como references, extends, files, include y exclude
  • También ofrece una compatibilidad mejorada con frameworks frontend modernos como Vue, Svelte, Solid y Qwik

Mayor compatibilidad con variables globales y APIs de Node

  • Se cambia el comportamiento para que objetos globales de Node.js como Buffer, global, setImmediate y clearImmediate siempre estén presentes también en el código del usuario
  • Variables globales que antes eran exclusivas para paquetes npm ahora pueden usarse directamente sin flags del comando
  • Se alcanza más del 95% de compatibilidad para node:buffer, node:events, node:querystring, node:quic, node:wasm y otros, y se seguirá ampliando
  • La versión base de tipos @types/node también se actualiza a 22.15.14

Cambios en la gestión de paquetes npm locales

  • El nombre de la opción para vincular paquetes npm locales cambia de patch a links, alineándose con el significado de npm link
  • Al usar la opción anterior, se muestra una advertencia de deprecación, lo que permite una gestión de paquetes más clara

Mejoras en LSP y productividad de desarrollo

  • Junto con mejoras de rendimiento y funciones en LSP, también se ofrecen varias comodidades, como soporte de sockets Unix/Vsock en fetch, callback onListen del servidor, gestión del kernel de Jupyter, lectura de comentarios en plugins de lint y compatibilidad Markdown en tablas de bench/coverage
  • También se mejoran el reconocimiento de señales Ctrl+Close en Windows (windows SIGHUP) y el formato Markdown en la salida de texto de bench/coverage

Agradecimiento a la comunidad y colaboradores

  • El avance de Deno 2.4 contó con una gran participación y retroalimentación de diversos contribuidores de la comunidad
  • Para más información y cambios detallados, se puede consultar la página de releases en GitHub

Conclusión

  • Deno 2.4 ofrece grandes avances en múltiples frentes, como bundling, importación de archivos externos, observabilidad, permisos/seguridad, compatibilidad y productividad
  • Permite una experiencia de desarrollo integrada fácil y potente en flujos modernos de desarrollo y proyectos del ecosistema frontend y Node
  • La información adicional, las noticias más recientes y el historial completo de cambios pueden consultarse en la documentación oficial, el blog y la página de releases en GitHub

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-08
Comentarios en Hacker News

  • Me gusta mucho el concepto de Deno, así que intenté aplicarlo lo más posible en un proyecto monorepo con Next.js, Hono y paquetes privados, usando Deno.json, JSR, imports modernos, Deno Deploy, etc. Hono funcionó bien y de forma limpia, pero Next.js no, y también hubo casos donde se rompían sutilmente temas de tipos. Recuerdo que elegir el destino de despliegue (como Vercel) también era un problema. Comparto un problema pequeño que tuve como ejemplo en este enlace al issue. En cambio, Bun, aunque no se sentía tan limpio como Deno, requería pensar menos y daba la impresión de simplemente “funcionar”. Eso sí, Bun tampoco es perfecto, por ejemplo Vercel no soporta el runtime de Bun

    • El consejo sería que la elección de stack seguía siendo demasiado centrada en npm, especialmente en un entorno con muchos paquetes npm privados. Creo que lo atractivo del enfoque de Deno está en elegir por cuenta propia un stack amigable con Deno o con ESM. Tuve buenas experiencias usando Lume o apuntando a Deno Deploy. (El score de JSR también ayuda a explorar librerías interesantes y con buena compatibilidad ESM). Claro, empezar con un stack completamente nuevo no es algo fácil en la práctica, y ya hay mucha inversión en cosas como Next.js, así que cuesta recomendar Deno. Pero donde realmente brillan sus ventajas es en un entorno que arranca desde cero con herramientas Deno-native y ESM-native. Por cierto, la compatibilidad de Deno con npm está mejorando cada vez más, y en las notas de la versión 2.4 también hay mejoras relacionadas. En entornos full-stack, priorizar package.json sobre deno.json da mejor compatibilidad, así que aunque a largo plazo empujes deno.json, también recomiendo una configuración basada en package.json

    • Probé Deno en modo de compatibilidad con npm y me sorprendió que funcionara bastante bien. Se parece mucho a la forma de usar Bun. Si ejecutas deno install en un directorio con package.json, crea un node_modules liviano, y con el comando deno task something puedes ejecutar scripts definidos en package.json. Pero la forma propia de Deno muchas veces consume demasiado tiempo y se vuelve frustrante, y si luego quieres volver al entorno node/npm solo te complica más la vida. En conclusión, usar Deno junto con package.json es más llevadero

    • Al principio me fui all-in con Deno, pero había demasiados problemas pequeños y fue pesado. En comparación, Bun funciona bien sin que tengas que preocuparte por casi nada

  • La gente tiende a subestimar la compatibilidad de Deno con node. Espero que la introducción de una variable de entorno de compatibilidad ayude a su adopción. Sería aún más cómodo si comandos como denon la activaran automáticamente

    • En mi experiencia, la compatibilidad de Deno con node estuvo por debajo de lo esperado. Me tomó como una hora migrar a Deno un proyecto simple de unas 100 a 200 líneas, cuando en realidad debería haber tomado entre 5 y 10 minutos. Faltaban algunos métodos de node, la documentación relacionada era pobre y hasta funciones básicas había que descargarlas directamente desde URLs oscuras. Al portar la suite de tests terminé rindiéndome. En especial, el paso de CommonJS (CJS) a ESM fue muchísimo más doloroso de lo esperado, y para nada tan fácil como lo presentan los documentos oficiales de Deno. Tuve la experiencia de no poder portar toda la librería

    • Antes era bastante positivo con Deno, pero ahora ya no siento que haya una razón clara para usarlo en vez de Bun

  • Hay buenas opiniones sobre la lista de cambios recientes de Deno. Lo uso con satisfacción para scripts aleatorios y glue code (para machine learning, por ejemplo, uso python/uv), y tengo expectativas sobre el soporte futuro para gRPC y el comando de bundle

  • Todavía me parece curioso que Deno siga sin funcionar bien en FreeBSD. Los bindings de V8 basados en Rust todavía no han sido porteados

    • Me pregunto cuántos desarrolladores modernos de JavaScript realmente usan FreeBSD

    • Antes la portabilidad entre Unix era una medida de la limpieza del código, pero ahora me desconcierta que ya no se enfatice mucho la compatibilidad entre distintos sistemas Unix

    • Parece que sí está registrado en los ports de FreeBSD

    • Es bastante comprensible que no dediquen mucho esfuerzo al soporte de FreeBSD

  • Una opinión es que la razón por la que Deno no se usa más en producción es la falta de una base de datos estandarizada de vulnerabilidades. Se puede compensar con compatibilidad 100% con npm, pero en ese caso la mayoría de los paquetes populares de Deno quedarían fuera del alcance. En el fondo, que no haya un gestor central de paquetes (por diseño) es un reto. Preguntan si ha habido avances al respecto

    • Réplica: si la falta de una base de datos de vulnerabilidades de verdad fuera un gran problema en producción, entonces tampoco se podría usar C/C++. En la práctica, en C/C++ se revisan problemas de seguridad consultando bases de datos neutrales al lenguaje como CVE/GHSA. Además, en C muchas veces simplemente se venden archivos externos y ni siquiera se rastrean versiones. También existe el archivo deno.lock, así que quien se preocupa por esto puede usarlo para revisar una base de datos de vulnerabilidades según las versiones que está usando

    • La estructura de traer paquetes directamente desde una URL (como GitHub) se parece a Go, así que el mismo problema aplicaría también a Go

  • Me gusta que hayan vuelto a agregar el subcomando bundle. Qué bueno no tener que usar soluciones rebuscadas

  • Me sorprendió que para bundling eligieran esbuild en lugar de Rolldown, que está basado en Rust. Se supone que Rolldown pronto llegará a v1

    • esbuild es actualmente muy estable y maduro, mientras que Rolldown sigue cambiando rápido, así que elegir esbuild es lo más razonable

  • Me gusta mucho la dirección de Deno y siento que Node debió haber salido así desde el inicio. Lo que me preocupa es que Deno termine dejándose arrastrar por el “hype” de sus competidores y solo los siga sin cambios propios

    • Aunque también puede ser que Deno mismo haya sido percibido todo este tiempo como un competidor de Node.js impulsado por el “hype”\n

  • Sigo escuchando buenas opiniones sobre Deno. Gracias a eso hasta me está dando ganas de probar js

    • Hoy en día, empezar directamente con TS también es una buena opción

  • Apoyo a Deno desde la perspectiva de seguridad, pero me incomodó ver que en el sitio oficial recomiendan instalarlo con algo tipo curl mywebsite.com/foo.sh | sh. Claro, cada quien tiene un nivel distinto de tolerancia al riesgo, pero al menos si descargas el archivo y luego lo ejecutas, tú o el antivirus pueden revisarlo. El ecosistema Node/Deno + npm requiere bastante confianza por defecto. La guía oficial también ofrece la opción npm install -g deno además de curl | sh, y npm al menos tiene verificación básica de integridad de archivos y un escaneo simple de malware, así que parece relativamente más seguro. Aunque el sitio deno.land sea seguro a nivel de codebase, desde el punto de vista operativo no se puede garantizar al 100%, así que no considero que curl | sh sea una buena práctica de seguridad

    • No estoy de acuerdo con esa lógica. La mayoría de los scripts de instalación al final solo descargan y ejecutan binarios de cientos a cientos de miles de líneas hechos por el mismo autor. Si no confías en absoluto en el autor hasta el punto de asumir que su servidor podría entregar malware solo a ciertas IPs, entonces también podría incrustarlo a nivel binario, así que en realidad no deberías usar ese proyecto desde el inicio. La polémica de curl | sh parece haberse difundido porque es un argumento fácil y repetible, cuando el verdadero problema de seguridad sería revisar millones de líneas de código. Si te preocupa hasta un ataque MITM de una agencia gubernamental, entonces la única salida sería dejar de confiar en Internet por completo

    • Señalan que hay dificultades para el onboarding de nuevos usuarios. Aunque recomiendes usar npm, primero hay que tener npm instalado; y el sitio oficial de npm te dice que instales nvm, que a su vez también usa curl | sh. O sea, al final el camino de npm también cae indirectamente en el mismo problema

    • En la discusión sobre si npm install -g deno es realmente más seguro que curl | sh, el punto clave es: “¿qué sería más fácil de comprometer para un atacante, los servidores de npm o un servidor propio?”. Si puedes estar seguro de que no hubo una intrusión en el servidor propio, entonces no hay razón para que curl | sh sea menos seguro que npm install. Al final, desde la perspectiva de seguridad, ambos métodos pueden ser igual de vulnerables, así que si te vas al extremo, el verdadero problema sería usar Internet en sí

    • Crítica de que la implementación del sandbox de Deno se siente como tecnología de los 90, y que usarlo no sería realmente un buen hábito de seguridad

    • Me pregunto si existe algún caso real en el que un ataque mediante instalación con curl | sh haya tenido éxito