titulo: Nightwatch y Node.js 24: qué falla en tests de Drupal 11.4 meta_description: Drupal 11.4.8 corrige el fallo de Nightwatch con Node.js 24 (issue #3623728). Detecta si tu CI quedó afectado y elige entre actualizar core o fijar Node 22. keywords: Nightwatch Node.js 24 Drupal 11, fallos de Nightwatch en Drupal, tests frontend Drupal CI, cómo ejecutar Nightwatch Drupal 11 tags: Drupal, Drupal 11, Desarrollo web, JavaScript, Mejores prácticas de desarrollo categoria: Drupal slug: nightwatch-nodejs-24-tests-drupal-11-4 ---
Drupal 11.4.8 corrige el fallo de Nightwatch con Node.js 24 (issue #3623728). Si CI falló al actualizar Node, sube core o fija Node 22.
La suite de pruebas frontend de tu proyecto no se rompió por un cambio tuyo: el salto a Node.js 24 rompía la ejecución completa de las pruebas Nightwatch de core. El problema está corregido desde Drupal 11.4.8, así que tienes dos caminos —actualizar core o fijar temporalmente Node en la versión 22.x— según la ventana de mantenimiento que manejes.
Qué rompe exactamente Node.js 24 en Nightwatch
El issue #3623728 se titula "Node.js v24 upgrade fails all Nightwatch test runs" y describe un escenario peor que un test aislado roto: con Node.js 24 instalado, la suite completa de Nightwatch falla, no solo un caso de prueba puntual. En la práctica eso bloquea el pipeline entero: ningún job de CI puede dar verde, y el merge queda congelado aunque el código del sitio esté correcto.
La corrección entró en Drupal 11.4.8, publicado el 26 de septiembre de 2026 según la página de lanzamientos de drupal.org. Si trabajas sobre una rama 11.4.x, ese es el primer lugar donde debes estar.
El timing del fallo no es casual. Node.js 24 es versión de soporte a largo plazo (LTS) desde octubre de 2025, y las imágenes de CI de los proveedores más usados la van adoptando como versión por defecto o como "latest LTS". Un runner que ayer usaba Node 22 y hoy instala Node 24 sin que tú tocaras nada basta para que la suite se ponga roja. Por eso el error aparece en equipos que no hicieron ningún cambio en su configuración: el cambio vino del runner.
Cómo comprobar si tu pipeline quedó afectado
Antes de tocar código, confirma las tres variables del problema: versión de Node, versión de core y alcance del fallo.
# En el runner o en tu máquina local
node -v # ¿sale v24.x?
composer show drupal/core | grep versions # ¿estás en 11.4.7 o anterior?
Si node -v devuelve v24.x y core está por debajo de 11.4.8, ya tienes el diagnóstico. Para ver el fallo de forma reproducida, ejecuta la suite localmente con el mismo Node que usa CI:
yarn install
yarn nightwatch --tag smoke
Lectura de los resultados
Con Node 24 y core sin la corrección, verás la suite fallar de forma generalizada, no un stack trace único que apunte a un test tuyo. Ese patrón —todo roto de golpe tras un cambio de versión de Node— es la firma del issue #3623728. Si en cambio falla un solo archivo de test con error de aserción, el problema es tuyo y este artículo no aplica.
Vale la pena revisar también el historial del pipeline: busca cuándo apareció el primer fallo y compáralo con la fecha en que la imagen del runner rotó su versión de Node. Esa línea de tiempo te confirma la causa antes de gastar tiempo en otro lado.
Dos formas de corregirlo, según tu ventana de mantenimiento
Opción 1: actualizar core a Drupal 11.4.8
Es la corrección definitiva y la que conviene si ya estabas planeando un parche de seguridad o mantenimiento:
composer require "drupal/core:11.4.8" \
drupal/core-composer-scaffold \
drupal/core-project-message --update-with-dependencies
composer update drupal/core --with-all-dependencies
Después de actualizar, deja que el runner use Node 24 (ya no debería romper nada) y vuelve a lanzar el job de Nightwatch. Si el sitio tiene módulos contrib con restricciones estrictas de core, Composer te avisará antes de romper nada: en ese caso resuelve primero esas dependencias y repite el comando.
Opción 2: fijar Node en 22.x mientras migras core
Útil si necesitas verde en CI hoy mismo y la actualización de core requiere una ventana de prueba más larga. Fija la versión de forma explícita en el workflow:
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'yarn'
O añade un .nvmrc en la raíz del proyecto con 22 para que quien trabaje localmente use la misma versión:
echo "22" > .nvmrc
nvm use
La clave de esta opción es que sea temporal: anota en el ticket de trabajo la fecha límite para pasar a 11.4.8, o el "parche" se vuelve la configuración permanente del proyecto y la próxima rotación de versiones te toma desprevenido otra vez.
Cómo evitar que esto se repita con la siguiente versión de Node
El patrón de fallo —una versión nueva de Node rompiendo la suite de core— se va a repetir con Node 26. Hay tres medidas que lo mitigan:
- Nunca dejes
node-versionenlatestolts/*en CI. Fija el número exacto y deja que tu proceso de actualización (un PR de Dependabot o una tarea trimestral) sea quien lo suba. Una versión fijada falla de forma controlada y anunciada; una versión flotante falla un lunes a las 7 a. m. - Declara la compatibilidad en
package.json:
{
"engines": {
"node": ">=22 <25"
}
}
Con engine-strict=true en .npmrc, yarn install se niega a ejecutarse con una versión no soportada y el error aparece en la primera línea del log, no después de veinte minutos de suite.
- Suscríbete a los release notes de core. La página de lanzamientos de Drupal lista, como en 11.4.8, qué issues correige cada versión. Leer la lista de patches de un release tarda dos minutos y te dice si algo tocó tu pipeline antes de que lo descubras en CI.
Qué revisar si los fallos persisten tras actualizar
Si ya estás en 11.4.8 con Node 24 y la suite sigue rota, descarta el issue #3623728 y avanza por esta lista: compara nightwatch.json y las variables de entorno de tu CI contra las de un checkout limpio de core; verifica que yarn install no esté resolviendo una versión distinta de paquetes en tu lockfile (borra node_modules y yarn.lock de prueba y reinstala); y revisa si algún módulo contrib añade tests Nightwatch propios que no fueron probados con Node 24. El issue en drupal.org tiene el historial completo de la corrección, útil cuando necesitas confirmar el comportamiento esperado.
El siguiente paso concreto: ejecuta node -v y composer show drupal/core en tu runner ahora mismo. Con esos dos datos sabes en un minuto si estás ante este fallo o ante otra causa, y puedes decidir entre actualizar a 11.4.8 hoy o fijar Node 22 hasta tu próxima ventana de mantenimiento.
Preguntas frecuentes
¿Node.js 24 rompe solo Nightwatch o también otras pruebas de Drupal?
El issue #3623728 documenta fallos en la suite Nightwatch de core, que es la que corre pruebas frontend en navegador. Las pruebas de PHPUnit no dependen de Node.js y no se ven afectadas por este cambio de versión.
¿Puedo quedarme en Node 22 de forma indefinida?
Sí, siempre que tu versión de Node siga recibiendo actualizaciones de seguridad, pero cada versión LTS tiene un ciclo de soporte definido por el proyecto Node.js. Fijar Node 22 sin fecha de migración solo posterga el mismo problema cuando esa versión llegue a fin de soporte.
¿La corrección llega también a ramas anteriores de Drupal?
Drupal 11.4.8 es un parche de la rama 11.4.x. Si estás en una versión anterior de Drupal 11, el camino es primero subir a la última 11.4.x disponible y de ahí a 11.4.8; no existe un backport separado para este issue.
¿Cómo ejecuto Nightwatch solo con un tag en Drupal 11?
Con las dependencias de JavaScript instaladas (yarn install), usa yarn nightwatch --tag nombre_del_tag desde la raíz de core. Así validas rápidamente que la corrección funcionó sin correr la suite completa.
¿Qué hago si mis tests Nightwatch son propios, los de mi módulo?
Corre primero la suite de core con Node 24: si pasa, tu infraestructura está sana y el fallo está en tus tests. Revisa entonces que tus casos no dependan de APIs de navegador o de scripts de Node que hayan cambiado de comportamiento en la versión 24.
