{"id":503,"date":"2026-03-09T18:21:35","date_gmt":"2026-03-09T18:21:35","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/deno-20-in-production-2026-migration-from-nodejs-a\/"},"modified":"2026-03-18T22:31:16","modified_gmt":"2026-03-18T22:31:16","slug":"deno-20-in-production-2026-migration-from-nodejs-a","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/deno-20-in-production-2026-migration-from-nodejs-a\/","title":{"rendered":"Deno 2.0 en Producci\u00f3n 2026: Migraci\u00f3n desde Node.js y Qu\u00e9 Cambi\u00f3 Realmente"},"content":{"rendered":"

Empecemos con honestidad: migr\u00e9 a Deno 2.0 porque me lo pidieron en una<\/a> retro de equipo y yo, con toda la confianza del mundo, dije “dos semanas<\/a> m\u00e1ximo”. Spoiler: fueron cuatro semanas, un incidente en producci\u00f3n<\/a> a las<\/a> 11pm de un mi\u00e9rcoles, y una cantidad de tabs de GitHub<\/a> Issues que prefiero no recordar.<\/p>\n

Trabajo en un equipo de seis personas construyendo APIs para una plataforma de anal\u00edtica de contenido. Tres microservicios en Node.js 22, todos en TypeScript, todos usando ESM, con un mont\u00f3n de dependencias de npm que llevaban a\u00f1os ah\u00ed sin que nadie<\/a> los tocara. El candidato perfecto para la migraci\u00f3n, en teor\u00eda.<\/p>\n

Tres Microservicios, Cuatro Semanas, y un Mi\u00e9rcoles Muy Complicado<\/h2>\n

Eleg\u00ed empezar con el servicio m\u00e1s peque\u00f1o: un worker que procesa webhooks entrantes, transforma los payloads y los encola en Redis. Unas 800 l\u00edneas de TypeScript, cuatro dependencias directas en npm. Pens\u00e9 que ser\u00eda el caso ideal para validar el proceso antes de tocar los servicios m\u00e1s cr\u00edticos.<\/p>\n

Lo que no calcul\u00e9 fue que “cuatro dependencias directas” significa, con el \u00e1rbol completo, algo as\u00ed como 340 paquetes. Y Deno 2.0, aunque mejor\u00f3 enormemente la compatibilidad con npm respecto a versiones anteriores, sigue teniendo sus opiniones sobre ciertas cosas.<\/p>\n

La migraci\u00f3n inicial fue sorprendentemente fluida. Cambias el package.json<\/code> por un deno.json<\/code>, reemplazas las importaciones de npm con el prefijo npm:<\/code>, y listo. En teor\u00eda. Esto funciona bien:<\/p>\n

\/\/ Antes (Node.js)\nimport { Redis } from "ioredis";\nimport { z } from "zod";\n\n\/\/ Despu\u00e9s (Deno 2.0)\nimport { Redis } from "npm:ioredis@5.3.2";\nimport { z } from "npm:zod@3.22.4";\n<\/code><\/pre>\n
Aqu\u00ed empez\u00f3 lo interesante. Deno 2.0 con \"nodeModulesDir\": \"auto\"<\/code> resuelve la mayor\u00eda de los paquetes sin problema. Pero ioredis<\/code> usaba internamente node:tls<\/code> con opciones que Deno maneja de forma ligeramente distinta, y el resultado era que la conexi\u00f3n se establec\u00eda, enviabas un comando, y a los 90 segundos exactos el socket se cerraba silenciosamente. Sin error. Sin log. Nada.<\/p>\n
Lo encontr\u00e9 porque vi que mis m\u00e9tricas de latencia ten\u00edan spikes cada 90 segundos exactos \u2014 ese patr\u00f3n tan regular fue la pista. Abr\u00ed el issue #24891 en el<\/a> repositorio de Deno y result\u00f3 que ya estaba reportado desde noviembre de 2024. La soluci\u00f3n: pin de ioredis@5.3.3-rc.1<\/code> que parche\u00f3 el comportamiento, y configurar keepAlive: true<\/code> expl\u00edcitamente en el<\/a> cliente.<\/p>\n
Esto lo empuj\u00e9 un mi\u00e9rcoles a las<\/a> 7pm. El error volvi\u00f3 a las<\/a> 11pm porque en staging no se nota \u2014 el volumen es demasiado bajo. Me enter\u00e9 por un alert de Datadog.<\/p>\n
La Compatibilidad con npm en 2026:<\/a> Mejor, Pero No Perfecta<\/h2>\n
Ser\u00e9 directo porque he visto muchos posts que pintan esto de color de rosa.<\/p>\n
Deno 2.x mejor\u00f3 mucho la compatibilidad con el ecosistema npm. La mayor\u00eda de paquetes que no dependen de APIs nativas de Node.js funcionan sin cambios: zod<\/code>, date-fns<\/code>, lodash<\/code>, fastify<\/code> (s\u00ed, fastify en Deno) \u2014 sin problemas. Pero hay categor\u00edas donde las cosas se complican.<\/p>\n
Paquetes que usan __dirname<\/code> o __filename<\/code> son los primeros candidatos a romper. Deno los polyfilla, pero si el paquete hace algo creativo con esas rutas para cargar archivos relativos, el comportamiento puede diferir. Me pas\u00f3 con un SDK interno que cargaba templates desde el sistema de archivos \u2014 tres horas depurando algo que no deber\u00eda haber tardado m\u00e1s de veinte minutos.<\/p>\n
Despu\u00e9s est\u00e1n los paquetes con addons nativos o binarios de C++. sharp<\/code> para procesamiento de im\u00e1genes funciona v\u00eda npm:sharp<\/code>, pero el tiempo de instalaci\u00f3n en CI subi\u00f3 de 45 segundos a 3 minutos en nuestro caso porque Deno no cachea los binarios compilados igual que npm.<\/p>\n
El que m\u00e1s me sorprendi\u00f3: algunos paquetes que detectan el entorno hacen typeof process !== 'undefined'<\/code> para saber si est\u00e1n en Node \u2014 y Deno 2.0 expone un objeto process<\/code> para compatibilidad, as\u00ed que eso est\u00e1 bien. El problema viene cuando el paquete luego consulta process.versions.node<\/code> y espera una versi\u00f3n espec\u00edfica. Deno devuelve un valor emulado que no siempre cuadra con las expectativas internas del paquete.<\/p>\n
\/\/ Esto puede romper paquetes que verifican la versi\u00f3n de Node\nconsole.log(process.versions.node); \/\/ En Deno: "22.0.0" (emulado)\nconsole.log(Deno.version.deno);     \/\/ "2.2.4"\n\n\/\/ Para detectar si est\u00e1s en Deno:\nconst isDenoRuntime = typeof Deno !== "undefined";\n<\/code><\/pre>\n
JSR (el registro de paquetes de Deno) creci\u00f3 bastante en 2025. A principios de 2026 hay paquetes como @std\/http<\/code>, @std\/async<\/code>, @std\/encoding<\/code> que son de primera clase y funcionan perfectamente. Si puedes sustituir dependencias npm por equivalentes de JSR, la experiencia mejora notablemente.<\/p>\n
El Sistema de Permisos: Pesadilla Operacional o Ventaja Real<\/h2>\n
Cuando empec\u00e9 a migrar pens\u00e9 que el sistema de permisos iba a ser un dolor de cabeza. Que terminar\u00eda dando --allow-all<\/code> en producci\u00f3n<\/a> porque qui\u00e9n sabe qu\u00e9 permisos necesita ioredis<\/code> internamente, o cualquier otro paquete npm.<\/p>\n
Me equivoqu\u00e9, y de forma interesante.<\/p>\n
El proceso de descubrir los permisos que necesita tu aplicaci\u00f3n es inc\u00f3modo al principio \u2014 ejecutas sin permisos y Deno te dice<\/a> exactamente qu\u00e9 necesita \u2014 pero esa incomodidad te da algo valioso: un mapa de lo que<\/a> tu aplicaci\u00f3n realmente hace. Nuestro worker de webhooks necesitaba exactamente esto:<\/p>\n
\/\/ deno.json\n{\n  "tasks": {\n    "start": "deno run --allow-net=redis.internal:6379,api.externa.com:443 --allow-env=REDIS_URL,WEBHOOK_SECRET,LOG_LEVEL --allow-read=\/etc\/ssl\/certs src\/main.ts"\n  },\n  "nodeModulesDir": "auto",\n  "imports": {\n    "@std\/async": "jsr:@std\/async@^1.0.0"\n  }\n}\n<\/code><\/pre>\n
Eso es todo. Un servicio que en Node.js corr\u00eda con acceso total al sistema, en Deno corre con permisos expl\u00edcitos a una IP de Redis, un dominio externo, tres variables de entorno, y los certificados SSL. Si alguien introduce una dependencia que intenta leer \/etc\/passwd<\/code> o hacer una petici\u00f3n a un dominio desconocido, Deno lo bloquea en runtime.<\/p>\n
No s\u00e9 si esto escala a aplicaciones con 50 dependencias y comportamientos din\u00e1micos complejos \u2014 probablemente hay casos donde terminas en --allow-all<\/code> de todas formas. Pero para servicios peque\u00f1os y bien definidos, cambi\u00f3 c\u00f3mo pienso sobre la seguridad de lo que<\/a> pongo en producci\u00f3n<\/a>.<\/p>\n
El Tooling Integrado: Lo Que<\/a> No Calcul\u00e9<\/h2>\n
Yo asum\u00eda que el formatter, linter y test runner integrados de Deno eran un nice-to-have para proyectos<\/a> peque\u00f1os. Despu\u00e9s de<\/a> cuatro meses, es lo que<\/a> m\u00e1s valoro del ecosistema \u2014 y no lo vi venir.<\/p>\n
No porque deno fmt<\/code> sea mejor que Prettier (honestamente son bastante similares en resultado). Sino porque elimina una categor\u00eda completa de<\/a> discusiones en el equipo. Sin archivo .prettierrc<\/code>. Sin conflictos de versi\u00f3n entre eslint<\/code> y typescript-eslint<\/code>. Sin “\u00bfqu\u00e9 configuraci\u00f3n de<\/a> eslint usamos?” El standard es el runtime.<\/p>\n
La primera semana, un compa\u00f1ero que lleva seis a\u00f1os en Node.js me pregunt\u00f3 c\u00f3mo configurar el linter. Le respond\u00ed que no hab\u00eda configuraci\u00f3n. Se qued\u00f3 callado un momento y luego dijo “ah, \u00bfentonces funciona?” S\u00ed, funciona.<\/p>\n
El test runner tambi\u00e9n. deno test<\/code> soporta cobertura de c\u00f3digo<\/a> nativa, watch mode, y el mismo formato de describe\/it<\/code> al que est\u00e1s acostumbrado si vienes de Jest o Vitest:<\/p>\n
import { assertEquals, assertRejects } from "jsr:@std\/assert";\nimport { processWebhook } from ".\/webhook.ts";\n\nDeno.test("procesa payload v\u00e1lido correctamente", async () => {\n  const payload = { event: "push", repo: "mi-repo" };\n  const result = await processWebhook(payload);\n  assertEquals(result.status, "queued");\n  assertEquals(result.jobId.startsWith("job_"), true);\n});\n\nDeno.test("rechaza payload sin firma", async () => {\n  await assertRejects(\n    () => processWebhook({}, { skipSignatureVerification: false }),\n    Error,\n    "Invalid signature"\n  );\n});\n<\/code><\/pre>\n
Sin instalar nada. Sin configurar nada. deno test<\/code> y ya.<\/p>\n
Deno Deploy merece una menci\u00f3n aparte: lo us\u00e9 para un cuarto servicio, este s\u00ed desde cero, y el workflow de deploy es genuinamente r\u00e1pido \u2014 push al repo, deploy en menos de 30 segundos, edge computing<\/a> global. Pero tiene sus propias restricciones (algunas APIs de filesystem no est\u00e1n disponibles, el modelo de<\/a> permisos cambia), as\u00ed que no es directamente equivalente a correr Deno en tu propio servidor.<\/p>\n
Cuatro Meses Despu\u00e9s: El Veredicto<\/h2>\n
Los tres microservicios est\u00e1n en producci\u00f3n<\/a>. Funcionan. No extra\u00f1o Node.js en<\/a> ninguno de ellos.<\/p>\n
Pero te ser\u00eda deshonesto si dijera que la migraci\u00f3n fue solo positiva. El tiempo real fue el doble de lo estimado. Las incompatibilidades de npm son reales y no siempre est\u00e1n documentadas \u2014 a veces simplemente tienes que probar y ver qu\u00e9 explota. El ecosistema de JSR, aunque crece, todav\u00eda no tiene la cobertura de npm para casos de uso especializados.<\/p>\n
Lo que s\u00ed cambi\u00f3: el tiempo de setup de proyectos nuevos baj\u00f3 bastante. El onboarding de un desarrollador nuevo es m\u00e1s simple porque hay menos configuraci\u00f3n que explicar. Los containers de Docker son m\u00e1s peque\u00f1os porque no llevamos node_modules<\/code>. Y el c\u00f3digo TypeScript se siente m\u00e1s limpio cuando Deno es tu target, porque usas las APIs web est\u00e1ndar (fetch<\/code>, WebSocket<\/code>, crypto<\/code>) directamente, sin polyfills.<\/p>\n
Mi recomendaci\u00f3n concreta: si tienes un servicio Node.js con pocas dependencias npm, bien tipado en TypeScript, y est\u00e1s dispuesto a invertir una o dos semanas<\/a> en la migraci\u00f3n, hazlo. Si tienes un monolito con 200 dependencias npm, c\u00f3digo legacy sin tipos, y deadlines apretados, no lo hagas todav\u00eda. No porque Deno sea malo, sino porque la fricci\u00f3n de compatibilidad va a comerte vivo.<\/p>\n
Para proyectos nuevos en 2026<\/a>, ya no considerar\u00eda Node.js como primera opci\u00f3n por defecto. Deno gan\u00f3 ese puesto en mi stack.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Empecemos con honestidad: migr\u00e9 a Deno 2.0 porque me lo pidieron en una retro de equipo y yo, con toda la confianza del mundo, dije \u201c dos semanas m\u00e1ximo\u201d.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-503","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=503"}],"version-history":[{"count":12,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/503\/revisions"}],"predecessor-version":[{"id":766,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/503\/revisions\/766"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}