Behavior changes#

This page explains the behavior-change blocks plan and run print, one per PHP and Laravel hop. Next: The baseline.

Some changes between versions do not raise an error: a function that still exists now means something else, a config key that was optional is required, a default that flipped. Rector rewrites what it knows; the silent changes need a human eye. So plan and run carry a curated list of them, one block per PHP and Laravel hop, plus the package rows on the last step, where the lock lands. A booster should know its own payload.

Behavior changes to check:
  Config key needed (config/app.php)
    check: Add the key.
  Minimum PHP raised
    check: Check the runtime.

Each entry says what changed (label), what keeps the old behavior when there is anything (keep old:), what to verify (check:), and where the app touches it: file:line hits for code, the file for config and package rows, no location for rows that apply everywhere. It is advisory, like the scans: it never changes the exit code, and nothing prints when nothing matches. In JSON output the entries land under behaviour_changes, per step, with the fields id, label, keep_old, check, source, hits and total.

An entry may also carry an optional parity object: one observable thing, how to read it before the hop, what it must equal after, and how to measure it. When a matched entry has one, the block gains a Parity checks section under the same step, one [ ] row per entry, so you can write down the before value now and compare it after the hop. The field is optional; entries without it print exactly as before.

{
  "parity": {
    "what": "How long a flashed toast stays open",
    "before": "The timer value the app sets today (SWEET_ALERT_TIMER in .env or 'timer' in config/sweetalert.php)",
    "after": "SWEET_ALERT_TOAST_AUTO_CLOSE (or 'toast.auto_close') must equal that value",
    "how": "Fire a toast and time it with a stopwatch"
  }
}

The list lives in data/behaviour-changes.json, bundled with the phar. An entry names the hop it applies to (php-80-to-81, laravel-10-to-11, or package:vendor/name@2 for a floor a package raises), how to find it (detect: a function, method, class, property, string token, blade snippet, config file and key, composer package, or always), and a source link that confirms the change:

{
  "id": "laravel-11-config-key",
  "hop": "laravel-10-to-11",
  "detect": { "kind": "config", "file": "config/app.php", "key": "cipher" },
  "label": "Config key needed",
  "keep_old": null,
  "check": "Add the key.",
  "source": "https://laravel.com/docs/11.x/upgrading"
}

Only confirmed changes ship, each with its source link, and at most three always rows per release, so the block stays a checklist rather than a pamphlet. To add an entry, append it to the data file and let the loader's errors tell you what is missing.