Comprobador de actualizaciones (Node 26, Laravel 13 y TypeScript 7)

Qué hace esta herramienta

Le pegas el manifiesto de tu proyecto —package.json si vas a Node 26, composer.json si vas a Laravel 13, tsconfig.json si vas a TypeScript 7— y te devuelve lo que se rompe, ordenado por impacto y con el cambio concreto para cada caso. Si además pegas la salida del comando del paso 2, revisa también tu código y te señala el archivo y la línea.

Las reglas no son genéricas: salen de los análisis de este sitio sobre qué se rompe al actualizar a Node 26, los cambios que rompen en Laravel 13 y qué se rompe en TypeScript 7. Cada hallazgo enlaza la sección que lo explica con el código de antes y después.

Por qué un grep y no tu repositorio

El comando del paso 2 es un grep -rn que busca solo los patrones que cambian en esa versión. Su salida trae la ruta y el número de línea de cada coincidencia (tests/Feature/CheckoutTest.php:18:…), así que la herramienta puede decirte dónde está cada problema sin ver el resto de tu código. Todo se analiza en el navegador y no sale ninguna petición con lo que pegas.

Lo que detecta en Node 26

• engines.node que deja fuera la 26, o que todavía admite Node 22 o anteriores.
• Addons nativos (bcrypt, better-sqlite3, canvas…) que necesitan binario para el ABI 147, y node-sass, que no lo va a tener.
• Agentes de observabilidad y cargadores (dd-trace, @opentelemetry/*, tsx…) que viven en la capa de module.register(), ahora deprecada.
• El flag --experimental-transform-types, que ya no existe.
• En el código: require('_stream_readable') y compañía, res.writeHeader(), require sin extensión en paquetes ESM, llamadas a fetch que Undici 8 puede rechazar y la imagen de Docker o la matriz de CI que siguen en una versión vieja.

Lo que detecta en Laravel 13

• laravel/framework y php que no admiten la 13, y si vienes de la 10 u 11, el aviso de ir versión a versión.
• Las dependencias que suben con el framework: laravel/tinker ^3.0, phpunit ^12.0, pest ^4.0 y laravel/boost ^2.0.
• laravel/helpers, cuyo array_first() choca con el del polyfill de PHP 8.5.
• En el código: VerifyCsrfToken en tests y rutas, upsert() con uniqueBy vacío, $event->exceptionOccurred, QueueBusy, rutas con dominio, pivotes polimórficos, factories de Str, callbacks de extend, las vistas pagination::default y Js::from.

Lo que detecta en TypeScript 7

• Las opciones del tsconfig.json que ya no existen: baseUrl, target: "es5", downlevelIteration, moduleResolution: "node" y "classic", module: "amd"/"umd"/"systemjs"/"none", y esModuleInterop, allowSyntheticDefaultImports o alwaysStrict en false. Lee el archivo con comentarios y comas finales, como lo lee tsc.
• Te da el bloque paths reescrito sin baseUrl, con cada destino relativo al tsconfig y con ./ delante. Es el cambio que suele hacerse a medias: si solo quitas baseUrl, sale TS5090.
• Del package.json: si tu rango de typescript salta a 7 sin que lo decidas, qué dependencias necesitan la API que 7.0 no trae (typescript-eslint, ts-jest, ts-morph, Vue, Svelte, Astro, MDX) y el paquete de compatibilidad que te deja compilando con 6 sin que lo notes.
• De la salida pegada: si npx tsc y el binario real no son la misma versión, el TS5101 («is deprecated and will stop functioning in TypeScript 7.0»), que delata que sigues en 6, y los scripts de CI que esperan el código de salida 2.

Lo que ninguna herramienta ve desde fuera

Hay cambios que dependen de tu entorno y no de tus archivos: los prefijos de caché y de sesión de Laravel si no están fijados en el .env, o las cabeceras de fetch que llegan de una base de datos. Por eso el resultado termina con una lista para revisar a mano. Un informe limpio es buena señal, no un permiso: pasa la suite entera antes de mover producción.