La versión estable de Next.js corona semanas de canarios centrados en Turbopack, mientras pnpm estrena una herramienta de caché para integración continua, PostgreSQL adelanta la beta 3 de su próxima versión mayor y Terraform prueba en RC un bloque de valores efímeros, en medio de la tensión de licencia que sostiene al fork abierto OpenTofu.
La versión, del 13 de agosto, corona el ciclo de afinamiento de Turbopack que esta sección viene documentando desde el 12 de agosto, mientras la rama canary sigue sumando ajustes.
Vercel publicó, el 13 de agosto de 2026, la versión estable 16.3.1 de Next.js, según el registro oficial de lanzamientos del proyecto en GitHub. La versión incorpora las correcciones acumuladas durante semanas de versiones canary del empaquetador Turbopack: ajustes al caché de imágenes, a los estilos de styled-jsx, al reemplazo de módulos en caliente (HMR) y a la limpieza de manifiestos de rutas ya borradas. Dos días después, el 14 y el 15 de agosto, Vercel siguió publicando versiones canary sobre esa misma base —16.3.1-canary.19 y 16.3.1-canary.20—, que suman un nuevo sistema de metadatos para el renderizado y ajustan la recuperación de hidratación en el navegador cuando la conexión se pierde antes de completarse, según el mismo registro de cambios. Esta sección documentó, el 12 y el 15 de agosto, sucesivas tandas de canarios centradas en acelerar y estabilizar el caché de Turbopack; la versión 16.3.1 es la primera etiquetada como estable desde que ese ciclo empezó, aunque el registro de cambios consultado para esta nota no confirma que Turbopack ya sea el empaquetador por defecto fuera del modo de desarrollo —Vercel sigue publicando canarios sobre el mismo número de versión, lo que indica que el trabajo de afinamiento continúa en paralelo a la etiqueta estable. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Next.js en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Next.js, pero el framework sigue siendo una opción dominante entre agencias y startups locales que construyen aplicaciones web con React, a las que conviene fijar la versión 16.3.1 en sus proyectos de producción y seguir tratando cada canario posterior como una vista previa de trabajo en progreso.
El equipo de pnpm publicó, el 15 de agosto de 2026, la versión 11.22 del gestor de paquetes, según el registro oficial de lanzamientos en GitHub. La novedad central es el comando pnpm cache path, que imprime el directorio donde pnpm guarda su caché de metadatos, lo que permite a sistemas de integración continua cachear el registro de verificación de lockfiles y saltarse la revalidación de lockfiles que no cambiaron contra las políticas de cadena de suministro configuradas. La misma versión acelera la resolución de versiones de Node.js: una vez verificada por firma, la metadata de cada versión queda en caché local, y los entornos de ejecución fijados (pinned) dejan de necesitar acceso a la red después de la primera descarga. El mismo día, pnpm publicó también la sexta candidata a lanzamiento (RC 6) de la versión 12, según el mismo registro de cambios: la novedad más visible es que pnpm ahora puede instalar y ejecutar otros gestores de paquetes —npm, Yarn Classic, Yarn Berry, Yarn 6 y Bun— con verificación de firma, de modo que un proyecto construido con Yarn puede instalarse en una máquina que solo tiene pnpm disponible, a través de un nuevo sistema de shims (pnpm shim add) y de una versión mejorada de pnpm dlx que descarga la versión real del gestor en lugar de un envoltorio de npm. El registro de cambios consultado para esta nota no confirma todavía una fecha de disponibilidad general para la versión 12 estable. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor de paquetes gana terreno entre equipos locales que manejan monorepos de JavaScript y TypeScript, a los que conviene revisar el nuevo comando cache path como una forma concreta de acortar los tiempos de verificación de dependencias en sus canalizaciones de integración continua.
El PostgreSQL Global Development Group publicó, el 13 de agosto de 2026, las versiones 18.6, 17.11, 16.15, 15.19 y 14.24, junto con la beta 3 de PostgreSQL 19, según el comunicado oficial en postgresql.org. El anuncio detalla más de 110 errores corregidos entre las cinco ramas activas, mejoras en decodificación lógica, replicación, comportamiento del planificador de consultas, la biblioteca cliente libpq y varios módulos contrib, además de soporte para OpenSSL 4 y datos de zona horaria actualizados a tzdata 2026c. El paquete también corrige 28 vulnerabilidades, entre ellas CVE-2026-19385, un desbordamiento de búfer en montón (heap buffer overflow) en la utilidad pg_dump con una puntuación CVSS de 8,8 sobre 10 que permite ejecución de código arbitrario, según el mismo comunicado. Publicar cinco ramas de mantenimiento y una beta el mismo día es la cadencia trimestral habitual del proyecto, pero el volumen acumulado —más de un centenar de correcciones en un solo ciclo— también refleja el costo de sostener en paralelo cinco versiones mayores con soporte activo; la versión 14, la más antigua de las cubiertas hoy, deja de recibir parches el 12 de noviembre de 2026, según el propio comunicado, lo que obliga a cualquier equipo que siga en esa rama a planificar una migración antes de esa fecha. La información de esta nota proviene del comunicado oficial de PostgreSQL, sin cobertura cruzada de otro medio verificada al cierre de esta edición. Costa Rica no publica cifras propias de adopción de PostgreSQL, pero la base de datos es una opción estándar entre bancos, aseguradoras y empresas de zonas francas que operan backend propio en el país, a las que conviene aplicar los parches de la rama que usen y revisar si corren PostgreSQL 14 de cara al fin de soporte de noviembre; la beta 3 de la versión 19, en cambio, es material solo para pruebas, no para producción.
HashiCorp publicó, el 12 de agosto de 2026, la primera candidata a lanzamiento de Terraform 1.16 (v1.16.0-rc1), junto con una versión alfa de la rama 1.17, según el registro oficial de lanzamientos en GitHub. Entre las novedades: un nuevo bloque store dentro de terraform_data que permite guardar valores efímeros y sensibles fuera del estado (state) del proyecto; soporte para usar bloques nested como valores computados en definiciones de recursos de proveedores; la posibilidad de usar bloques import dentro de módulos, algo que antes solo funcionaba en la configuración raíz; binarios preconstruidos para arquitectura Linux s390x (zLinux); y nuevos modos de falla —halt, taint y continue— para los disparadores de acciones sobre recursos. Terraform es, desde 2023, un caso central de disputa de licencia en el ecosistema de infraestructura como código: ese año HashiCorp cambió la licencia del proyecto de la abierta Mozilla Public License 2.0 a la Business Source License, restringiendo su uso comercial competitivo, lo que llevó a un grupo de empresas a crear OpenTofu, un fork que la Linux Foundation aloja bajo licencia MPL 2.0 y que sigue publicando su propia rama de desarrollo, según describe el propio repositorio del proyecto en GitHub. Cada mejora que HashiCorp anuncia para Terraform 1.16 —incluida esta candidata a lanzamiento— llega bajo los términos de esa licencia restringida, mientras OpenTofu decide de forma independiente cuáles de esas funciones replica y cuáles no en su propia base de código abierta. La información de esta nota proviene del registro de lanzamientos oficial de Terraform en GitHub y del repositorio de OpenTofu, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Terraform u OpenTofu, pero equipos de plataforma e infraestructura de empresas locales que operan en la nube pública usan alguna de las dos herramientas para aprovisionar recursos, a los que conviene revisar bajo qué licencia corre su herramienta de infraestructura como código antes de decidir si prueban esta candidata a lanzamiento.
— La primera candidata a lanzamiento de la versión 1.16, del 12 de agosto, añade un bloque store para guardar valores sensibles fuera del state y permite usar bloques import dentro de módulos.
cat /feed/herramientasdevastro.md
La versión 7.2.0, del 6 de agosto, evita regenerar páginas estáticas sin cambios, mientras el parche 7.2.2, del 13 de agosto, corrige límites de descriptores de archivo durante la construcción.
> > astro --version
> El proyecto de código abierto Astro publicó, el 6 de agosto de 2026, la versión 7.2.0, según el registro oficial de lanzamientos en GitHub. La novedad principal es el soporte experimental para builds estáticos incrementales, activable con la bandera experimental.incrementalBuild: cuando las dependencias de un módulo y las claves de caché de datos no cambiaron, Astro salta la regeneración de esa página estática, y las entradas de colecciones de contenido pueden declarar una propiedad digest para señalar cambios sin tener que recalcular el hash de todo el contenido. La misma versión suma un modo astro preview --background que arranca el servidor de vista previa como proceso en segundo plano, con subcomandos para consultar su estado, ver sus registros o detenerlo desde un script.
> > astro build --incremental
> Dos parches posteriores completaron la secuencia: 7.2.1, del 11 de agosto, corrigió el reemplazo en caliente (HMR) de hojas de estilo CSS y violaciones de política de seguridad de contenido (CSP); y 7.2.2, del 13 de agosto, corrigió problemas de estilos de componentes, ajustó el comportamiento de los builds incrementales y resolvió un límite de descriptores de archivo abiertos que podía interrumpir construcciones grandes, según el mismo registro de cambios. La función de builds incrementales responde a un reclamo habitual de equipos que operan sitios con miles de páginas de contenido: hasta ahora, cambiar una sola entrada obligaba a Astro a regenerar el sitio completo en cada despliegue.
> > astro --why
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Astro en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Astro, pero el framework gana terreno entre agencias locales que construyen sitios de contenido y marketing con muchas páginas, a las que conviene probar la bandera experimental.incrementalBuild en un proyecto no crítico antes de activarla en un despliegue de producción.
JetBrains publicó, el 12 de agosto de 2026, la candidata a lanzamiento de Kotlin 2.4.20 (2.4.20-RC), según el registro oficial de lanzamientos en GitHub. Entre los cambios: una nueva bandera -XheaderModeType=compilation que mejora el rendimiento de la compilación de cabeceras J2KLIB; correcciones a dos excepciones de conversión de tipo (ClassCastException) del compilador, una al descartar resultados de funciones suspendidas dentro de bloques when y otra en propiedades de extensión de miembro delegadas a referencias de propiedad enlazadas; y, en el compilador de Compose, la corrección de un manejo incorrecto de funciones composable singleton dentro de funciones con parámetros de tipo. La versión también activa por defecto la compilación incremental para Kotlin/Native, hasta ahora una opción que había que habilitar de forma manual. Esta candidata llega dos meses después de la beta 2 de la misma serie, publicada el 22 de julio, y confirma el ritmo habitual de Kotlin de sumar una versión menor cada pocas semanas dentro de la rama 2.4.x, según el mismo registro de cambios; el equipo también actualizó las pruebas de integración de Gradle a la versión 9.7 y mejoró el rendimiento de sincronización de Gradle para proyectos multiplataforma. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Kotlin en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Kotlin, pero el lenguaje es el estándar de facto para desarrollo Android entre equipos de banca móvil y fintech locales, a los que conviene tratar esta candidata como una vista previa de prueba en integración continua antes de que llegue la versión estable 2.4.20.
Las versiones 1.20260814.1 a 1.20260816.1, publicadas entre el 14 y el 16 de agosto, ajustan el manejo de reintentos de Durable Objects y retiran serialización obsoleta del caché.
Cloudflare publicó, de forma automatizada y casi diaria, tres versiones más de workerd, el motor de ejecución de Cloudflare Workers, entre el 14 y el 16 de agosto de 2026, según el registro oficial de lanzamientos en GitHub. La versión 1.20260814.1 corrigió el manejo de una bandera de sobrepaso (bypass) de llamadas RPC, mejoró mensajes de error y sumó generación de metadatos de reintento para Durable Objects; la 1.20260815.1, del día siguiente, mejoró la búsqueda de alternativas (fallback) de NMR, reforzó el contexto de trazas (SpanContext) y renovó el manejo del tipo jsg::Nullable; y la 1.20260816.1, publicada hoy mismo, eliminó código de serialización obsoleto usado por el método Cache PUT. Esta sección documentó, el 13 de agosto, una tanda anterior de lanzamientos de wrangler y workerd que activaron por defecto la compatibilidad con Node.js en Cloudflare Workers; la secuencia de esta semana confirma que Cloudflare sostiene una cadencia de publicación casi diaria para workerd, generada por su propio flujo de integración continua, un ritmo inusual frente a la mayoría de proyectos de infraestructura de código abierto, que suelen agrupar cambios en lanzamientos semanales o mensuales. El registro de cambios consultado para esta nota no detalla el impacto directo de estos ajustes para código de usuario que no dependa de Durable Objects o del método Cache PUT. Costa Rica no publica cifras propias de adopción de Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que ya corren funciones de borde sobre la plataforma pueden revisar el registro de cambios de workerd antes de fijar una fecha de compatibilidad (compatibility date) más reciente en sus proyectos.
Entre una versión estable que corona un ciclo de canarios y una beta que adelanta la próxima versión mayor de PostgreSQL, esta edición documenta siete desarrollos recientes en el ecosistema de programación.
Esta edición documentó siete desarrollos entre el 6 y el 16 de agosto de 2026: la versión estable 16.3.1 de Next.js, que corona semanas de canarios centrados en Turbopack; la versión 11.22 de pnpm, con su nuevo comando cache path, y la sexta candidata de la versión 12; las versiones 18.6, 17.11, 16.15, 15.19 y 14.24 de PostgreSQL junto con la beta 3 de la versión 19; la primera candidata a lanzamiento de Terraform 1.16, con su nuevo bloque de valores efímeros; la versión 7.2 de Astro, que estrena builds estáticos incrementales; la candidata a lanzamiento de Kotlin 2.4.20; y tres versiones más de workerd que Cloudflare publicó casi a diario esta semana. El hilo que domina la edición es la maduración de herramientas de construcción: Next.js, pnpm y Astro publicaron en la misma semana mejoras centradas en evitar trabajo repetido —caché de Turbopack, caché de verificación de lockfiles, builds incrementales—, mientras Terraform recordó, con su bloque de valores efímeros, que buena parte de la infraestructura como código sigue dividida entre la rama con licencia restringida de HashiCorp y el fork abierto OpenTofu que sostiene la Linux Foundation desde 2023. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas concretas: fijar Next.js en la versión 16.3.1 antes de adoptar canarios posteriores; probar el comando pnpm cache path como ahorro directo de tiempo en integración continua; y revisar si algún proyecto propio corre PostgreSQL 14, de cara al fin de soporte de esa rama el 12 de noviembre.