Upgrade Checker (Node 26, Laravel 13 and TypeScript 7)

What this tool does

Paste your project’s manifest —package.json if you are moving to Node 26, composer.json for Laravel 13, tsconfig.json for TypeScript 7— and it returns what breaks, sorted by impact, with the concrete change for each case. If you also paste the output of the step 2 command, it checks your code too and points at the file and line.

The rules are not generic: they come from this site’s breakdowns of what breaks when upgrading to Node 26, what actually breaks in Laravel 13 and what breaks in TypeScript 7. Every finding links the section that explains it, with before-and-after code.

Why grep output and not your repository

The step 2 command is a grep -rn that looks for only the patterns that change in that version. Its output carries the path and line number of every match (tests/Feature/CheckoutTest.php:18:…), so the tool can tell you where each problem is without seeing the rest of your code. Everything is analyzed in the browser and no request carries what you paste.

What it catches for Node 26

• An engines.node that excludes 26, or that still allows Node 22 or older.
• Native addons (bcrypt, better-sqlite3, canvas…) that need a binary for ABI 147, and node-sass, which will not get one.
• Observability agents and loaders (dd-trace, @opentelemetry/*, tsx…) that live in the now-deprecated module.register() layer.
• The --experimental-transform-types flag, which no longer exists.
• In your code: require('_stream_readable') and friends, res.writeHeader(), extensionless require in ESM packages, fetch calls Undici 8 may reject, and the Docker image or CI matrix still pinned to an older version.

What it catches for Laravel 13

• laravel/framework and php constraints that do not allow 13, and, if you are on 10 or 11, the warning to go one major at a time.
• The dependencies that move with the framework: laravel/tinker ^3.0, phpunit ^12.0, pest ^4.0 and laravel/boost ^2.0.
• laravel/helpers, whose array_first() clashes with the PHP 8.5 polyfill’s.
• In your code: VerifyCsrfToken in tests and routes, upsert() with an empty uniqueBy, $event->exceptionOccurred, QueueBusy, domain routes, polymorphic pivots, Str factories, extend callbacks, the pagination::default views and Js::from.

What it catches for TypeScript 7

• The tsconfig.json options that no longer exist: baseUrl, target: "es5", downlevelIteration, moduleResolution: "node" and "classic", module: "amd"/"umd"/"systemjs"/"none", and esModuleInterop, allowSyntheticDefaultImports or alwaysStrict set to false. It reads the file with comments and trailing commas, the way tsc does.
• It hands you the rewritten paths block without baseUrl, each target relative to the tsconfig and starting with ./. It is the change people get half right: remove only baseUrl and you get TS5090.
• From package.json: whether your typescript range jumps to 7 without you deciding, which dependencies need the API 7.0 does not ship (typescript-eslint, ts-jest, ts-morph, Vue, Svelte, Astro, MDX), and the compatibility package that leaves you compiling with 6 without noticing.
• From pasted output: whether npx tsc and the real binary disagree, the TS5101 (“is deprecated and will stop functioning in TypeScript 7.0”) that gives away you are still on 6, and CI scripts expecting exit code 2.

What no tool sees from outside

Some changes depend on your environment, not your files: Laravel’s cache and session prefixes when they are not pinned in .env, or fetch headers that come from a database. That is why the result ends with a manual checklist. A clean report is a good sign, not a green light: run the whole suite before moving production.