pnpm publicó la undécima candidata de la versión 12 el 25 de agosto mientras sostiene en paralelo la rama estable 11.24, Prisma sumó dos candidatas de la versión 8 en un solo día con un cambio de ruptura en su API, mise pulió los mensajes de error un día después de migrar su analizador de comandos a usage-rs, GitHub Copilot CLI llegó a su novena entrega desde el 18 de agosto, Next.js retocó el caché de Turbopack en su rama canary, y Cloudflare workerd llegó a catorce días consecutivos de lanzamientos, personaje de la semana en esta sección.
La undécima candidata de pnpm 12, publicada el 25 de agosto, permite aprobar paquetes en lote mientras el equipo sostiene en paralelo la rama estable 11.24, publicada apenas un día antes.
El equipo de pnpm publicó, el 25 de agosto de 2026 a las 09:49 UTC, la versión 12.0.0-rc.11 del gestor de paquetes, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización permite que el comando pnpm stage approve apruebe varios paquetes en cuarentena ("staged") de una sola vez, en lugar de uno por uno: ejecutado sin parámetros ofrece selección interactiva, o puede recibir una lista de identificadores directamente; el lote completo se aprueba con una sola contraseña de un solo uso, procesa los paquetes en el orden que exigen sus dependencias dentro del monorepositorio y salta automáticamente cualquiera cuyas dependencias no estén aprobadas. La misma versión corrige cómo los miembros raíz de componentes Bit sin archivo package.json reciben enlaces simbólicos bajo el enlazador nodeLinker: isolated, y ajusta el mensaje de actualización para sugerir pnpm self-update cuando la instalación la gestiona PNPM_HOME, según el mismo registro de cambios. Es la undécima candidata del ciclo de pruebas de la versión 12, que arrancó el 7 de agosto con la rc.1 y ya acumula cambios de ruptura de fondo: esa primera candidata cambió cómo pnpm resuelve dependencias de Git alojadas en GitHub, GitLab o Bitbucket —ahora usa siempre URLs HTTPS canónicas en lugar de conservar el transporte SSH original, lo que elimina un problema de reproducibilidad entre máquinas distintas— y movió la salida de comandos como pnpm root -g a la salida de error estándar para no ensuciar la salida de datos. El mismo 24 de agosto, un día antes de esta rc.11, el equipo publicó también la versión 11.24.0 de la rama estable actual, con aprobaciones globales de compilación ("global build approvals") y una decena de correcciones menores, según el mismo repositorio: dos ramas de desarrollo activas en paralelo, una prueba de que la migración a la versión 12 no interrumpe el soporte de la rama que usan hoy la mayoría de los equipos. El equipo de pnpm no ha anunciado, en el registro de cambios consultado para esta nota, una fecha estimada para la versión 12.0.0 estable. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor de paquetes gana terreno entre equipos locales de JavaScript que buscan instalaciones más rápidas que npm, para quienes conviene esperar a la versión estable antes de migrar flujos de integración continua que dependan del formato de lockfile, dado que la rc.1 ya cambió ese formato para dependencias de Git.
La versión 2026.8.12, publicada el 24 de agosto, un día después de cambiar su analizador de línea de comandos por usage-rs, transforma bloqueos y advertencias mudas en errores que señalan ruta y motivo.
El equipo de mise publicó, el 24 de agosto de 2026 a las 08:33 UTC, la versión 2026.8.12 del gestor de versiones de herramientas de desarrollo, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización agrega un enlace de desinstalación (PackageUninstall) para gestores de paquetes usados en el arranque ("bootstrap"), que antes solo funcionaba con Homebrew; corrige el análisis de archivos de configuración con marca de orden de bytes UTF-8, que antes hacía desaparecer entradas de versión completas; preserva los comentarios al editar la configuración desde el propio programa; y detiene advertencias falsas sobre archivos de configuración deshabilitados intencionalmente. En el terreno de errores, la CLI ahora muestra la ruta y la causa concreta cuando falla la navegación entre directorios en lugar de interrumpirse ("panic"), maneja correctamente las interrupciones por SIGINT durante tareas en curso, señala directorios de herramientas vacíos con sugerencias de instalación, y refiere el archivo de configuración de origen cuando una variable no se expandió, según el mismo registro de cambios. La versión llega un día después de que mise reemplazara la biblioteca clap por usage-rs como analizador de línea de comandos, el cambio técnico más profundo del ciclo reciente, que exige Rust 1.95 o superior para compilar el proyecto desde el código fuente. Esta sección viene documentando la migración de herramientas de desarrollo hacia Rust como uno de los hilos activos del mes: Bun reescribió el 20 de agosto cerca de un millón de líneas de su núcleo de Zig a Rust con ayuda de agentes de inteligencia artificial, y oxc sigue puliendo su conjunto de herramientas para JavaScript, nacido directamente en Rust. La entrega de hoy encaja en ese mismo patrón como su fase menos vistosa pero más necesaria: convertir bloqueos y mensajes crípticos en errores legibles es exactamente el trabajo de estabilización que suele seguir a un cambio de analizador de comandos, no una función nueva que atraiga titulares. La información de esta nota proviene únicamente del registro oficial de lanzamientos de mise en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de mise, pero equipos locales que fijan, dentro de un mismo repositorio, las versiones exactas de Node.js, Python o Ruby que necesitan lo usan cada vez más como alternativa a asdf, y ninguno de los cambios de hoy rompe la compatibilidad de comandos existente, según el mismo registro de cambios.
El equipo de Prisma publicó, el 25 de agosto de 2026 a las 10:22 UTC, la versión 8.0.0-rc.7 del ORM, según el registro oficial de lanzamientos del proyecto en GitHub. El cambio central es de ruptura: los métodos de paginación .take(n) y .skip(n) de las colecciones del ORM sobre SQL y MongoDB se renombran a .limit(n) y .offset(n), y los nombres anteriores se eliminan por completo —el constructor de consultas de bajo nivel de MongoDB conserva .skip(n) porque coincide con el nombre nativo de esa etapa del pipeline—; el motor de referencia (peer) sube a @prisma/cli-engine@0.2.3. Horas antes, a las 07:03 UTC del mismo día, la rc.6 había cambiado cómo el ORM representa las columnas temporales de PostgreSQL: fecha, marca de tiempo y hora ahora exigen que cada columna use valores del tipo Temporal o una representación en texto en lugar del objeto Date de JavaScript, y eliminó la instalación de "agent skills" del comando prisma orm init, que pasa a vivir únicamente en el comando prisma init a nivel de familia, según el mismo repositorio. Es ya la séptima candidata de lanzamiento de la versión 8 desde que el ciclo arrancó el 7 de agosto con la rc.1, y el ritmo de cambios de ruptura no baja con el número de candidata: la rc.5, publicada el 22 de agosto, todavía corregía una pérdida de conexiones del motor sobre PostgreSQL —el comportamiento más básico de mantener una base de datos conectada—, y dos candidatas después, la rc.7 de hoy sigue modificando la forma misma del constructor de consultas que cualquier prueba existente invoca directamente. Que un método tan central como la paginación cambie de nombre en la séptima ronda de pruebas, en lugar de en las primeras, pone en duda qué tan cerca está realmente la versión 8 de congelar su superficie pública, más allá de que el propio proyecto siga llamando "candidata de lanzamiento" a cada entrega. Prisma no ha publicado, en el registro consultado para esta nota, una fecha estimada para la versión 8.0.0 estable. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Prisma en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Prisma, pero el ORM es una opción común entre startups locales que usan Node.js y TypeScript sobre PostgreSQL en zonas francas tecnológicas, a las que conviene posponer cualquier migración de código que use .take() o .skip() hasta que el proyecto confirme que la superficie de la API dejó de moverse.
GitHub publicó, el 24 de agosto de 2026 a las 17:42 UTC, la versión 1.0.81-9 de Copilot CLI, según el registro oficial de lanzamientos del proyecto en GitHub. El único cambio documentado agrega enlaces a más información dentro de las advertencias de retención de datos que el selector /model ya mostraba junto a cada modelo disponible, para que la persona usuaria pueda revisar cómo ese proveedor conserva las instrucciones y respuestas antes de elegirlo, según el mismo registro de cambios. Es la novena entrega de la serie 1.0.81 desde la v1.0.81-1 del 18 de agosto, un ritmo cercano a una versión por día que esta sección viene documentando como cadencia habitual de la herramienta. A diferencia de entregas anteriores de la misma semana —restauración de sesiones y dictado por voz el 21 de agosto, razonamiento "xhigh" para Grok 4.6 el 23 de agosto—, la de hoy es un ajuste menor de transparencia, sin función nueva. Que GitHub publique una versión completa por un solo enlace agregado confirma que la cadencia diaria de Copilot CLI responde a lo que esté listo cada día, no a un calendario de lanzamientos por lote como el que sigue la versión de Copilot integrada en el navegador, que GitHub resume semanalmente en su changelog. La información de esta nota proviene únicamente del registro oficial de lanzamientos de GitHub Copilot CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de GitHub Copilot CLI, pero la herramienta gana terreno entre equipos de desarrollo locales que automatizan tareas de programación asistida, para quienes el cambio de hoy no exige ninguna acción más allá de revisar, si lo desean, la política de retención de datos del modelo que tengan seleccionado.
El equipo de Next.js publicó, el 24 de agosto de 2026 a las 23:45 UTC, la versión 16.4.0-canary.6 del framework, según el registro oficial de lanzamientos del proyecto en GitHub. Los cambios: las tareas programadas de turbo-tasks se ejecutan de inmediato cuando se leen en lugar de esperar su turno; se revirtió un cambio anterior que registraba la duración del caché para rutas con renderizado parcial ("PPR") de tipo bloqueante, por considerarse prematuro; el servidor de desarrollo limpia archivos de salida obsoletos de Turbopack en el directorio de compilación al iniciar; se corrigió la clave de caché para el precargado de metadatos cuando la ruta incluye parámetros de búsqueda; y se mejoró el manejo de errores de existencia de archivos en la resolución de módulos de Turbopack, según el mismo registro de cambios. Es la cuarta compilación canary en tres días, después de la canary.2 del 22 de agosto, y la canary.3 y canary.4 del 23 y 24 de agosto. Que el equipo revierta, en lugar de solo sumar, un cambio de caché para rutas con renderizado parcial confirma que el sistema de caché persistente de Turbopack —la apuesta de Vercel para acelerar tanto el desarrollo local como los arranques en frío en producción— todavía se ajusta en casos de borde específicos, no solo se completa de forma incremental. La rama estable actual sigue siendo la 16.3.2, publicada el 21 de agosto como una entrega de corrección de errores sin las funciones pendientes de la serie canary, y el equipo no ha anunciado fecha para una versión 16.4.0 estable en el registro consultado para esta nota. Costa Rica no publica cifras propias de adopción de Next.js, pero el framework es una de las bases más comunes entre agencias y startups locales que construyen aplicaciones web con React, para quienes conviene seguir tratando la serie 16.4.0-canary como vista previa inestable y mantener la producción sobre la rama estable 16.3.x mientras el equipo termina de ajustar el caché de Turbopack.
— La versión 16.4.0-canary.6, publicada el 24 de agosto, revierte un cambio de caché para rutas con renderizado parcial y limpia archivos de compilación obsoletos al iniciar el modo de desarrollo.
cat /feed/devopscloudflareworkers.md
La versión 1.20260825.1, publicada el 25 de agosto, retoma cambios de código reales tras dos jornadas de solo cambiar la marca de versión, y extiende a catorce la racha diaria del motor de Cloudflare Workers.
> > workerd --version
> Cloudflare publicó, el 25 de agosto de 2026 a las 00:49 UTC, la versión 1.20260825.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la decimocuarta versión consecutiva que la compañía publica en otros tantos días, racha que arrancó el 12 de agosto y que esta sección declaró personaje de la semana el lunes pasado. A diferencia de las dos entregas anteriores, del 23 y el 24 de agosto, que solo llevaban un cambio de marca de versión sin tocar código, la de hoy trae cambios reales: preserva las respuestas automáticas de WebSocket que quedan en tránsito durante una actualización del entorno de ejecución (ticket interno STOR-5552), retiene los marcos de contexto asíncrono entre distintos alcances ("scopes"), introduce flujos de compresión respaldados por TypeScript con un contexto de compresión consolidado, y limpia la implementación interna de EventTarget y AbortSignal, según el mismo registro de cambios.
> > workerd diff v1.20260824.1..v1.20260825.1
> Que la racha retome cambios de código justo el segundo día de la semana en que esta sección la sostiene como personaje de la semana responde a la pregunta que dejaron abiertas las dos jornadas anteriores, sin cambios funcionales: la cadencia diaria de workerd no sustituye el trabajo de ingeniería real, coincide con él cuando lo hay y se reduce a un simple aumento de versión cuando no. Catorce días sin una sola interrupción, del 12 al 25 de agosto, siguen siendo el hilo más sostenido de esta categoría en lo que va del mes.
> > echo $COSTA_RICA
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que ejecutan Workers con WebSockets de larga duración pueden actualizar sin cambios de configuración adicionales, dado que la preservación de respuestas automáticas en tránsito es aditiva, según el mismo registro de cambios.
Entre la undécima candidata de pnpm 12 y el cambio de ruptura en la API de paginación de Prisma, esta edición documenta seis desarrollos recientes en el ecosistema de programación.
Esta edición documentó seis desarrollos del 24 y el 25 de agosto de 2026: la versión 12.0.0-rc.11 de pnpm, undécima candidata de la nueva versión mayor, publicada en paralelo a la rama estable 11.24; la versión 2026.8.12 de mise, que convierte fallos silenciosos en mensajes de error un día después de migrar su analizador de comandos a usage-rs; las versiones 8.0.0-rc.6 y rc.7 de Prisma, publicadas el mismo día, con un cambio de columnas temporales de PostgreSQL y un renombre de la API de paginación; la versión 1.0.81-9 de GitHub Copilot CLI, novena entrega desde el 18 de agosto; la versión 16.4.0-canary.6 de Next.js, que ajusta el caché de Turbopack; y la versión 1.20260825.1 de Cloudflare workerd, decimocuarta entrega consecutiva de una racha que arrancó el 12 de agosto. El hilo que domina la jornada es cuánto tarda una "candidata de lanzamiento" en dejar de cambiar su superficie pública: Prisma sigue renombrando métodos centrales de su ORM en la séptima candidata de la versión 8, y pnpm acumula once candidatas de la versión 12 sin fecha de versión estable, mientras ambos proyectos mantienen en paralelo sus ramas actuales sin interrupción para quienes todavía no migran. Cloudflare Workers y su motor workerd cierran el martes como personaje de la semana en esta sección: catorce días consecutivos de lanzamientos, del 12 al 25 de agosto, hoy con cambios de código reales tras dos jornadas de solo versión. Para equipos de desarrollo en Costa Rica, la lista de hoy queda mayormente en fase de observación: ninguno de los seis desarrollos exige una acción inmediata en producción, salvo posponer cualquier migración de código que use los métodos take() o skip() de Prisma hasta que la versión 8 confirme que dejó de cambiar, y tratar tanto pnpm 12 como Next.js 16.4 todavía como ramas de vista previa.