Laravel Auto Presenter Laravel Package

Getting Started

Version 4.0 is a compatibility release: the headline change is Laravel 10 support. There is no published migration guide, no changelog beyond that line, and no feature or breaking-change notes — so treat this as a "verify, don't assume" upgrade.

Minimal steps:

1. Read the release itself first, then the source. With a one-line changelog, the composer.json constraint is your real documentation. Check the illuminate/* requirements and the PHP floor before planning anything.
2. Confirm your own version pair. Laravel 10 requires PHP 8.1+. If you are still on L8/L9 or PHP 8.0, this release is not for you and there is no partial-upgrade path documented.
3. Diff the tags. Run git diff <previous-tag>..4.0.0 -- composer.json src/ config/ in the package's repository. Given the changelog's silence, this is the only reliable way to find out whether "supports L10" also means "drops L8/L9", renamed config keys, or bumped dependency majors.
4. Do a throwaway install before touching a real app. composer require <package>:^4.0 in a scratch Laravel 10 skeleton. If the resolver fights you, you have your answer in thirty seconds instead of an afternoon.

First use case: a Laravel 10 upgrade blocked by this package's constraint. Bump the constraint, run the test suite, and treat any failures as undocumented breaking changes until proven otherwise.

Implementation Patterns

Because the release adds nothing new to the API surface, the day-to-day patterns that matter here are upgrade and compatibility patterns, not feature patterns.

Constraint-based upgrade check. Before editing application code, verify the resolver agrees:

composer why-not <vendor>/<package> 4.0
composer update "<vendor>/<package>:^4.0" --with-dependencies --dry-run

why-not is the single most useful command in a sparse-changelog upgrade: it names the exact conflicting package and version, which the changelog will never tell you.

Isolate the bump in its own commit. One commit for composer.json + composer.lock, nothing else. When something breaks three weeks later you can bisect to a single dependency change rather than unpicking a mixed diff.

Pin the major, not the patch. Use ^4.0 in require so patch releases flow, and lean on composer.lock for reproducibility in the application. If you maintain a package that depends on this one, widen rather than narrow: "^3.0|^4.0" if the API is genuinely unchanged, so your consumers are not forced to upgrade in lockstep. Only do this after the diff in Getting Started confirms nothing moved.

Framework-matrix CI. Since 4.0 is defined entirely by its Laravel 10 support, your CI should encode that pairing:

matrix:
  php: ['8.1', '8.2']
  laravel: ['10.*']

If you still support older Laravel on the 3.x line, keep a second job on the old matrix so the 4.x job can be strict about deprecations without breaking your own downstream users.

Test against the real container. Compatibility bumps most often fail in service-provider registration, config publishing, and facade resolution — none of which unit tests with mocks will catch. Keep one or two integration tests that boot the full application and resolve the package's bindings, and let those be your upgrade canary.

Publish and diff config on upgrade. Even with no documented config changes, run php artisan vendor:publish --tag=<package>-config --force into a temp path and diff against your committed config. Silent default changes are a classic "compatibility release" side effect.

Gotchas and Tips

"Supports L10" does not mean "supports only L10" — or that it supports L9. The single sentence is ambiguous in both directions. Resolve it from composer.json, never from the changelog. If the constraint is ^10.0 only, then 4.0 is a hard cutoff for anyone on L9, and that is a breaking change for your dependency graph even though nothing in the library changed.

Undocumented breaking changes are the default risk here. A release note this thin usually means either (a) genuinely nothing changed but the constraint, or (b) the maintainer did not write down the renames. Assume (b) until the diff proves (a). Grep the diff for @deprecated, removed methods, and changed config keys specifically.

PHP 8.1 is the floor. Laravel 10 drops PHP 8.0. If your deployment image, CI, or a transitive dependency is pinned below 8.1, the install will fail in a way that looks like a package problem but is not.

Watch for framework-deprecation noise turning into failures. If your test suite converts deprecations to exceptions (PHPUnit's convertDeprecationsToExceptions, or E_ALL error handlers), expect new failures on L10 that are Laravel's own deprecations surfacing through the package, not regressions you introduced. Triage those separately before assuming the upgrade broke something.

Check the package's own CI matrix. If the repository's build matrix does not actually include Laravel 10, treat the claim as unverified and smoke-test the paths you depend on yourself. This is a two-minute check that saves a production surprise.

Debugging a resolver conflict. Order of operations: composer why-not → read the conflicting package's constraint → check whether an updated release of that package exists → only then consider --ignore-platform-reqs (and almost never in production, since it defers the failure to runtime).

Extension points are the escape hatch. If 4.0 turns out to break something you rely on and the maintainer is unresponsive, the package's service provider bindings and config are usually the seam to override — bind your own implementation in a downstream provider rather than forking. Confirm the binding is still $app->bind()-able in the 4.0 source before committing to that plan.

Pin and record your reasoning. Whatever you decide, leave a note in the upgrade commit explaining why 4.0 was adopted (L10 compatibility) and what you verified (diff reviewed, matrix green). The next person to read this changelog will have exactly as little information as you did.