Laravel Starter Kit React Laravel Package

Getting Started

No prior assessment exists for this package, so this entry is effectively the baseline. The only documented change in v1.3.0 is a minimum PHP requirement bump to 8.5 — there are no listed API changes, new features, or deprecations. Treat this release as a platform constraint change, not a feature release, and do your diligence accordingly.

First three steps before installing anything:

1. Confirm the requirement. Open composer.json in the package root and look at the require.php constraint. A jump to ^8.5 means Composer will refuse to install the package on any 8.3/8.4 runtime — including your CI images, your local Herd/Valet/Sail container, and any long-lived production host still on an older minor.
2. Check your own ceiling. Run php -v locally and check your composer.json require.php and your CI matrix (.github/workflows/*.yml, phpunit.xml, docker-compose.yml, Dockerfile). If you pin php: 8.4, you cannot adopt v1.3.0 yet.
3. Read the diff, not just the notes. git diff v1.2.x..v1.3.0 -- composer.json and then the full diff. A release note that says only "upgrade PHP" frequently also carries #[Override] attributes, typed constants, ?-> cleanups, and dropped @var docblocks that never made the changelog.

First use case: pin the package in a feature branch alongside a PHP 8.5 runtime, install, and run your existing test suite unchanged. The goal of that first run is to prove nothing in the package's public surface moved — not to build anything new.

Implementation Patterns

Constraint-first adoption. Upgrade the runtime before the package, never both at once. Sequence: bump the PHP image in CI and local tooling → run the existing suite on 8.5 against the old package version → confirm green → bump the package to v1.3.0 → run again. If both steps are done in one commit, a failure tells you nothing about which side broke.

Matrix the boundary deliberately. In CI, keep a job on the oldest PHP your application still claims to support, and add one on 8.5. When the package requires ^8.5, the old-PHP job must exclude the package or be dropped — model this explicitly rather than letting Composer resolve differently per job:

strategy:
  matrix:
    php: ['8.4', '8.5']
    include:
      - php: '8.4'
        composer-flags: '--no-dev'   # package v1.3.0 not installable here

Freeze via platform config while you plan. If you need the rest of the tree on 8.4 but want to see what v1.3.0 would resolve to, use config.platform.php in a throwaway branch. Do not ship platform overrides to production — they let Composer install packages whose true requirement your runtime does not satisfy, which turns a resolution error into a runtime fatal.

Container and image pinning. If you ship Docker, pin the base image to an explicit minor (php:8.5-cli-alpine) rather than php:8-cli. A floating tag will silently roll you onto 8.5 and, combined with a composer.lock written on 8.4, can produce install failures on deploy that never appeared locally.

Lockfile hygiene across the boundary. composer.lock contains a platform block recording the PHP version it was generated on. Regenerate the lock on the new runtime (composer update --lock or a clean composer install after deleting it) and commit the result — otherwise review diffs will be noisy and CI may disagree with local.

Version-gate in shared libraries. If you maintain internal packages that depend on this one, widen your constraint rather than pinning: "vendor/package": "^1.3" with your own require.php raised in lockstep. Pinning an exact patch version across a monorepo turns one upstream constraint change into N coordinated PRs.

Gotchas and Tips

"Upgrade PHP to version 8.5" is a breaking change in semver-minor clothing. Raising the minimum PHP is conventionally treated as a minor by many maintainers, but it will break installs. Read the constraint as authoritative and treat v1.3.0 as effectively major for planning purposes. If you cannot move to 8.5 — EOL policy, managed hosting, a hard dependency on an extension not yet built for 8.5 — stay on the last 1.2.x release and pin "^1.2" explicitly so a composer update does not pull you across.

Watch for silent deprecation noise from 8.4 baseline deprecations. Several deprecations landed in 8.4 (notably implicit nullable parameter types, e.g. function f(Foo $x = null)) that become noisier under 8.5. If the package's own source was not fully audited, you may see Deprecated: notices in logs that were previously suppressed by error_reporting. Grep the lockfile and vendor tree for = null on typed params if you see unexpected notice volume after upgrading.

Check composer why-not. If composer require vendor/package:^1.3 fails, composer why-not vendor/package 1.3.0 gives you the exact conflicting package and constraint, which is far faster than reading the resolver's prose.

Debugging dependency failures. In order: composer validate, composer why-not, composer diagnose, then composer update -vvv. The resolver output at -vvv names the platform package (php) among the candidates; a line reading requires php ^8.5 -> your php version (8.4.x) does not satisfy that requirement is the tell.

Extension points to check before assuming nothing changed. Even a constraint-only release can touch composer.json extra.laravel (provider aliases, discovery), the service provider's register()/boot() order, or published config defaults. Run php artisan vendor:publish --tag=<package>-config --force on a scratch branch and diff the published config against your committed copy — an unnoticed config key change is the classic post-upgrade regression.

Laravel-version interaction. PHP 8.5 support in the framework itself landed in specific Laravel minor versions. Verify laravel/framework in your composer.lock is a release that explicitly lists PHP 8.5 support; running a framework version that predates 8.5 support on an 8.5 runtime produces subtle failures (serialization, reflection, deprecation-to-exception conversion in tests) that look like package bugs.

Treat the empty changelog as a signal, not a guarantee. With no feature entries, the useful verification is behavioural: run your test suite with -d error_reporting=E_ALL and -d zend.assertions=1, and diff the output against the 8.4 run. Anything that appears only on the new runtime belongs to this upgrade, and having that baseline captured now saves you an afternoon when v1.4.0 arrives.

Pin, then relax. Adopt as "vendor/package": "1.3.*", not "^1.3", for the first production cycle. Once you have run it through real traffic, relax to ^1.3. The extra minute of constraint editing is cheaper than discovering a 1.4.0 surprise during an incident.

Escalation if the release is unusable. If you need 8.5-only fixes but cannot take the minimum-version bump, the maintainable options are: fork and relax the constraint (accepting that you support PHP versions upstream does not test), or stay on 1.2.x and backport individual patches. Do not use --ignore-platform-reqs in CI as a permanent workaround — it disables the check for every package in the tree, not just this one.