Laravel Autobuilder Laravel Package

Getting Started

• Check your runtime first. v1.4.0 requires PHP 8.4+. If any app, CI runner, or local Sail/Valet/Herd image is still on 8.3, stop here and upgrade PHP before touching the dependency — Composer will hard-fail on the platform requirement otherwise.
• Read the upgrade as a platform bump, not an API change. The release explicitly states "no behaviour change intended"; the only real breaking item is the minimum PHP version. Look at the composer.json require.php constraint first, then the CHANGELOG entries for v1.0.8–v1.2.7 that were reconstructed — those are the only record of behaviour between your current pinned version and this one.
• First use case: run composer update <vendor>/<package> --with-dependencies on a branch, then composer why-not php 8.4 / composer outdated to see whether anything still pins you below 8.4. Once installed, exercise your existing test suite — that is the meaningful smoke test here, because the release is a maintenance pass.
• Nothing new to learn API-wise. This is not a feature release; your existing integration points, config file, and service provider registration stay as they are. Budget time for the PHP upgrade, not for re-reading docs.

Implementation Patterns

• Pin and stage the runtime upgrade separately. Do the PHP 8.4 move as its own PR (base image, composer.json platform config, CI matrix) and merge it before or alongside the package bump. Mixing a runtime jump with dependency churn makes bisecting failures painful.
• Mirror the package's CI matrix. Upstream now tests on PHP 8.4 and 8.5. Align your own matrix to at least 8.4 so you catch the same class of issues they do, and consider adding 8.5 as an allowed-failure job to get early signal.
• Treat the docker/ image as a reference implementation. The package's Docker image moved to PHP 8.4 — if you copy or derive from it for local dev, re-pull rather than layering 8.4 packages onto a cached 8.3 base.
• Use composer.json platform config for reproducibility. If your host is 8.4 but a deploy target lags, set config.platform.php explicitly so resolution is deterministic across CI and production rather than silently differing per machine.
• Lock-file-driven rollout. Bump in one app, let it soak through a deploy cycle, then propagate across the fleet. With a no-behaviour-change release, this is cheap and catches environmental surprises early.
• Static analysis as the verification step. Because the release is a Rector-driven modernisation (first-class callables, ??=, === [] over empty(), explicit return types), your own PHPStan/Psalm run is the most direct confirmation that nothing in the public surface shifted under you.

Gotchas and Tips

• PHP 8.3 is a hard stop, not a warning. Composer will refuse to install. If you maintain a library that depends on this package, your own require.php constraint must be widened in the same release, and that ripples to your consumers — sequence it deliberately.
• "No behaviour change intended" is not a guarantee for extenders. The modernisation added explicit return types to arrow functions and closures and applied type-declaration rules. If you subclass package classes or override methods, verify signatures still match — a newly-added return type on a parent method can fatal your override. Run your suite, don't assume.
• Reconstructed CHANGELOG entries are lower fidelity. v1.0.8–v1.2.7 were rebuilt from release history rather than written at the time. Treat those entries as a summary of intent, not an exhaustive diff; when something looks off, git log/git diff between tags is the source of truth.
• Removed tracked junk can affect your fork. coverage.xml was untracked and gitignored. If you generate coverage into that path, confirm your tooling writes there fresh rather than assuming the file exists — and if you had a local modification to it, expect a merge conflict on the deletion.
• Debugging tips: if a failure appears after upgrading, first re-run with php -v and composer show <vendor>/<package> on the failing environment to confirm the actual runtime, then check whether opcache or a stale Docker layer is serving 8.3 bytecode.
• Extension points remain stable. No new config keys, no deprecations, no removed methods — so don't spend time hunting for migration docs; there aren't any beyond the PHP constraint and the CHANGELOG backfill.