Gutenberg migró de Jest a Vitest: qué cambia en 2026

En pocas palabras: Gutenberg migró sus tests unitarios y de integración en JavaScript de Jest a Vitest, según el anuncio oficial del 23 de septiembre de 2026 en Make WordPress Core. Desde @wordpress/scripts 36.0.0, Vitest es el motor por defecto para test-unit-js, con soporte ESM nativo y Browser Mode.

Gutenberg completó la migración de sus tests unitarios y de integración en JavaScript de Jest a Vitest, según confirmó el anuncio oficial en Make WordPress Core del 23 de septiembre de 2026. El cambio trae soporte nativo para módulos ESM y tests en navegador real vía Browser Mode.

Vitest es un framework de testing para JavaScript construido sobre Vite, con una API compatible con Jest pero con soporte nativo para ECMAScript Modules (ESM) y la posibilidad de correr tests en un navegador real en lugar de simularlo con jsdom. Gutenberg lo adoptó como reemplazo de Jest para sus tests unitarios y de integración, y desde la versión 36.0.0 de @wordpress/scripts es el motor de test por defecto para cualquier proyecto que use test-unit-js.

¿Por qué Gutenberg dejó de usar Jest?

Gutenberg cambió a Vitest porque el setup basado en CommonJS de Jest necesitaba cada vez más configuración manual para soportar dependencias que ya venían en formato ESM. El equipo mantenía una lista explícita de paquetes que Babel tenía que transformar para que Jest pudiera correrlos, y actualizar una dependencia solía implicar tocar también esa configuración.

Acá está el problema real: cada dependencia nueva era una apuesta. ¿Iba a romper el pipeline de tests o no? Nadie lo sabía hasta correrlo. Vitest tiene soporte nativo de ESM, así que ese tipo de fricción prácticamente desaparece.

Hay un segundo factor, menos técnico y más de ecosistema. Los propios mantenedores de Jest reconocieron un período de menor ritmo de desarrollo y menos releases, aunque destacaron mejoras de performance y compatibilidad en sus últimas versiones. Gutenberg apuntó a reducir configuración custom a largo plazo y, de paso, compartir el tooling de Vite que ya usa Storybook. La compatibilidad de las APIs de Vitest con las de Jest hizo posible una migración incremental en vez de una reescritura total.

Qué cambia con Vitest en los tests de Gutenberg

El cambio más visible es Browser Mode, que corre tests unitarios y de integración en un navegador real en lugar de simularlo. Con eso, los tests de componentes pueden verificar estilos computados, tamaños de elementos, scroll, foco y navegación por teclado sin recrear ese comportamiento con mocks de jsdom. En conocer más sobre la comunidad de WordPress profundizamos sobre esto.

jsdom no desaparece: sigue disponible para tests de DOM que no dependen del renderizado real del navegador. La convivencia de los tres entornos (Node, jsdom, Browser Mode) es justamente lo que permite elegir el nivel de fidelidad que necesita cada test sin pagar el costo de un navegador completo para todo.

• Ejecución en paralelo: según los benchmarks de migración citados por el equipo, los tests de Browser Mode terminaron antes que el grupo más largo de Node/jsdom, así que no determinaron el tiempo total de la corrida en esa configuración medida.
• Optimización de workers: el equipo también optimizó los workers de test y el setup compartido para reducir el tiempo total durante la migración.

¿Cómo se seleccionan los entornos de test por nombre de archivo?

El entorno de cada test lo define el sufijo del nombre de archivo, sin necesidad de tocar configuración adicional. Un archivo *.test.* sin sufijo corre en Node por defecto, *.jsdom.test.* corre en jsdom y *.browser.test.* corre en Browser Mode.

Esto cambia un hábito instalado desde hacía años en el ecosistema WordPress, donde Jest simulaba un entorno de navegador por defecto para casi todo. Ahora hay que elegir explícitamente.

• *.test.*: corre en Node. Es el default para lógica que no toca el DOM.
• *.jsdom.test.*: corre en jsdom, para estructura del DOM, eventos y estado que no dependen del renderizado real.
• *.browser.test.*: corre en Browser Mode, para CSS, layout e interacciones que sí dependen del navegador.

Ojo con un detalle importante: Browser Mode requiere tener un navegador instalado y usa APIs de renderizado e interacción de React distintas a las que usan los tests de jsdom. Los tests explícitamente importan describe, test, expect y vi desde vitest, y algunas APIs de mocking, assertions y opciones de línea de comandos difieren de Jest. Traducir un test viejo no siempre es copiar y pegar los imports. El Testing Overview del Block Editor Handbook, mencionado en el anuncio, cubre el setup completo y cómo elegir entorno.

Qué deben hacer los proyectos que usan @wordpress/scripts

Desde @wordpress/scripts 36.0.0, el comando wp-scripts test-unit-js usa el Vitest instalado por el propio proyecto, no uno bundleado. Esta versión trae cambios breaking en configuración, dependencias, APIs y opciones de línea de comandos, así que actualizar sin revisar la guía rompe el pipeline de CI. Relacionado: probar estos cambios en un entorno de staging.

Hay dos caminos y ninguno es «el equivocado»:

• Migrar a Vitest: seguir la guía de migración enlazada desde la documentación del paquete para actualizar dependencias, configuración, tests y comandos.
• Quedarse en Jest: cambiar el comando de wp-scripts test-unit-js a wp-scripts test-unit-jest, instalar las dependencias de Jest directamente y configurar el proyecto de forma explícita. Los tests y snapshots existentes pueden quedarse tal cual.

Quedarse en Jest no es solo cambiar el nombre del comando si tu proyecto dependía de los defaults que venían bundleados con @wordpress/scripts. El paquete ya no provee Jest, su entorno ni la configuración y el transformer de WordPress para Jest. Hay que armar eso a mano con los paquetes publicados. La configuración pública de test-unit en @wordpress/eslint-plugin 27.0.0 y las reglas por defecto de wp-scripts lint-js para unit tests también pasan a Vitest, así que si te quedás en Jest necesitás reglas de lint explícitas.

test-unit-jest queda como comando de mantenimiento, sin fecha de baja programada. Eso sí: las features nuevas de testing apuntan a Vitest de acá en adelante, no a Jest.

Qué pasa con los paquetes @wordpress/jest-preset-default y @wordpress/jest-console

@wordpress/jest-preset-default y @wordpress/jest-console quedan deprecados y no reciben más actualizaciones, pero las versiones ya publicadas siguen disponibles para los proyectos que se quedan en Jest. No hay planes de paquetes equivalentes para Vitest.

La razón que da el equipo es directa: gran parte de la funcionalidad que justificaba tener paquetes propios de WordPress ahora la cubre Vitest de forma nativa, con su propia configuración. Por eso no existen ni un @wordpress/vitest-preset-default ni un @wordpress/vitest-console. Ya lo cubrimos antes en mantener tu instalación de WordPress actualizada.

Hay un matiz que conviene tener presente. Vitest tiene spies que pueden chequear llamadas esperadas a console, pero hacer que un test falle automáticamente ante output inesperado de console requiere setup adicional explícito, algo que @wordpress/jest-console resolvía de fábrica.

Errores comunes al migrar de Jest a Vitest en Gutenberg

• Asumir que hay que migrar ya mismo: test-unit-jest sigue con soporte de mantenimiento y sin fecha de remoción. No hay apuro si el proyecto tiene una suite de Jest estable.
• Pensar que *.test.* sigue simulando un navegador: con Vitest, ese sufijo corre en Node por defecto. Si el test toca el DOM, hay que renombrarlo a *.jsdom.test.* o *.browser.test.* según corresponda.
• No instalar un navegador para Browser Mode: esos tests necesitan una instalación de navegador real, algo que Node y jsdom no requieren. Olvidarse de eso rompe el CI en el primer intento.
• Dar por sentado que @wordpress/jest-console tiene reemplazo directo: no lo tiene. Si tu suite dependía de que fallara ante console.error o console.warn inesperados, hay que configurar eso a mano con los spies de Vitest.

Preguntas Frecuentes

¿Por qué Gutenberg dejó de usar Jest y pasó a Vitest?

Gutenberg cambió a Vitest porque su setup con Jest, basado en CommonJS, necesitaba configuración manual creciente para soportar dependencias en formato ESM, incluyendo una lista explícita de paquetes que Babel debía transformar. A eso se sumó el reconocimiento de los propios mantenedores de Jest de un período de menor ritmo de desarrollo.

¿Qué es Vitest y en qué se diferencia de Jest?

Vitest es un framework de testing para JavaScript basado en Vite, con soporte nativo de ESM y APIs compatibles con Jest. La diferencia principal frente a Jest es que no necesita transformación adicional para módulos ESM y permite correr tests en un navegador real vía Browser Mode, algo que Jest no ofrece de forma nativa.

¿Los proyectos que usan @wordpress/scripts tienen que migrar sí o sí a Vitest?

No. Desde @wordpress/scripts 36.0.0, test-unit-js usa Vitest por defecto, pero los proyectos pueden quedarse en Jest cambiando al comando test-unit-jest e instalando las dependencias de Jest de forma explícita. Ese comando recibe mantenimiento y no tiene fecha de remoción anunciada. Sobre eso hablamos en revisar y arreglar enlaces rotos en tu sitio.

¿Qué pasa con los paquetes @wordpress/jest-preset-default y @wordpress/jest-console?

Ambos paquetes quedan deprecados y no reciben más actualizaciones, aunque sus versiones publicadas siguen disponibles para proyectos existentes en Jest. No hay planes de paquetes equivalentes para Vitest porque gran parte de esa funcionalidad ya la cubre Vitest de forma nativa.

¿Cómo se eligen los entornos de test (Node, jsdom, Browser Mode) en Gutenberg?

El entorno se elige por el nombre del archivo: *.test.* corre en Node, *.jsdom.test.* corre en jsdom y *.browser.test.* corre en Browser Mode con un navegador real instalado. No hay configuración global que defina el entorno por proyecto; se define test por test.

Conclusión

Gutenberg cerró la migración de Jest a Vitest para sus tests de JavaScript, y desde @wordpress/scripts 36.0.0 ese cambio también le llega a cualquier proyecto que use test-unit-js. Si mantenés un plugin o theme que depende de esos scripts, lo primero es decidir: migrar siguiendo la guía oficial, o pasar a test-unit-jest y configurar Jest a mano.

Lo que no da la fuente es un cronograma de remoción para test-unit-jest, así que no hay urgencia real para migrar mañana. Lo que sí conviene hacer antes de tocar nada en CI es correr la suite actual en un branch aparte con la versión nueva de @wordpress/scripts, revisar qué tests rompen por el cambio de entorno por defecto (de simulado a Node puro), y recién ahí decidir si vale la pena migrar los mocks de console y las assertions específicas de Jest, o quedarse un tiempo más con lo conocido.

Fuentes

• Make WordPress Core – Anuncio oficial de la migración de Jest a Vitest en Gutenberg