Laravel Beyond Laravel Package

Technical Evaluation

Package role. This is a Laravel scaffolding package for the Action–Domain–Responder pattern. v7.1.0 is a maintenance-plus-tooling release: it adds a generator (beyond:make:adr-action), adds Laravel 12.x to the support matrix, and removes Laravel 10.x.

Architecture fit. Fits cleanly. ADR is a single-action-controller convention layered on top of standard Laravel routing, the container, and HTTP kernel — the package does not replace framework primitives or introduce a runtime layer. Critically for risk assessment, the package's observable surface is developer tooling and conventions, not production request handling. Blast radius of a bad release is broken composer resolution and stale generators, not user-facing outages. That materially lowers the stakes of adopting it early.

Integration feasibility. High. Installation is Composer + auto-discovered service provider; the new command is additive and opt-in. No migrations, queues, cache drivers, or external services are implied by the release notes. The main integration work is convention alignment (naming, namespaces, where domain logic lives), which is a team decision, not a technical one.

Technical risk.

• Semver deviation (primary risk). Dropping Laravel 10 support in a minor release (7.1.0) is standard practice in the Laravel ecosystem but is formally a breaking change. The mitigation is entirely on the consumer: an app pinned to ^7.0 on Laravel 10 will simply stop advancing, while an app pinned to ^7.1 on Laravel 10 will fail to resolve. The insidious case is the former — a silently frozen dependency that stops receiving fixes. This is the risk to manage, and it is a process risk, not a code risk.
• Generated-code drift. Artisan generators copy stubs into the application. Upgrading the package does not upgrade already-generated actions, so stub improvements and convention changes arrive only for new files unless stubs are published and diffed deliberately. Expect divergence in long-lived codebases.
• Cadence signal. Adding Laravel 12 and removing Laravel 10 in the same release confirms the package tracks Laravel's annual major cycle. Budget for exactly one forced-major dependency event per year, correlated with the framework upgrade — not an independent risk, but a compounding one.
• Additive feature risk. The new make:adr-action command is low risk, but generator commands can conflict with existing files or published stubs. Verify overwrite behavior and any interactive prompts before scripting it.

Key questions.

1. What are the exact illuminate/* constraints and the PHP floor in composer.json? (Laravel 12 implies PHP 8.2+; confirm whether the floor moved for the whole 7.x line or only for the L12 branch.)
2. Will a 7.0.x patch/security branch be maintained for Laravel 10 consumers, and for how long?
3. Is the CI matrix actually green across Laravel 11 and 12, and across supported PHP versions, or is L12 support declared but lightly tested?
4. Does the new command overwrite existing files, prompt, or fail closed on collision?
5. Are stubs publishable and versioned, so generated code can be audited against the package version that produced it?
6. Does the package's own release history show a pattern of dropping framework majors in minor releases? (If yes, our pinning policy must assume it.)

Integration Approach

Stack fit. Targets Laravel 11.x and 12.x on PHP 8.2+. No hosting, infrastructure, or observability assumptions — it is portable across any Laravel deployment model, including serverless and containerized. Suitable for both greenfield services and existing apps willing to adopt a single-action-controller convention.

Migration path.

• Greenfield / Laravel 11–12: adopt directly at 7.1.0. No migration.
• Laravel 10 applications: blocked from 7.1.0. Two options: pin the dependency at ^7.0 and accept a frozen line, or defer adoption until the Laravel 11 upgrade completes. Do not attempt to hold a ^7.1 constraint on Laravel 10 — it will hard-fail resolution.
• Existing adopters on 7.0.x: upgrading to 7.1.0 requires no application code changes. The only delta is the new command, which is opt-in.

Compatibility checks before rollout. Transitive Composer constraints; orchestra/testbench and PHPUnit/Pest versions used in test suites; Larastan/PHPStan levels (generator output changes can trip analysis baselines); and whether published stubs collide with the new version's defaults.

Sequencing.

1. Inventory — enumerate repositories by Laravel major and record current package constraint. This is the gating step; everything else depends on it.
2. Pin explicitly — replace floating ^7 constraints with version-and-framework-aware pins per repository, so upgrades are deliberate rather than incidental.
3. CI matrix — add Laravel 12 to the build matrix where the app itself is on 12; do not add the package at 7.1.0 to a Laravel 10 pipeline.
4. Spike — trial beyond:make:adr-action on a short-lived branch, confirm output shape and overwrite semantics, and review generated code before adopting it as a team standard.
5. Codify conventions — publish stubs and write down the ADR layout (naming, namespace, where domain logic and responders live) before broad rollout. Convention debt is the expensive part of ADR adoption, not installation.
6. Schedule L10 sunset — tie it to the application's Laravel 11 upgrade, not to a separate date.

Operational Impact

Maintenance. Low ongoing operational burden — no runtime component to monitor. The real maintenance cost is dependency hygiene: one recurring, predictable upgrade ticket per year tied to Laravel's major release. Assign an owner; the failure mode of an unowned scaffolding package is a silent multi-year drift, not an incident.

Support. Support load is developer-facing and front-loaded: questions about conventions and code review feedback on generated actions, not production pages. Publishing stubs and documenting the layout converts most of this into self-service. Expect near-zero on-call impact.

Scaling. Scales with team size and codebase count, not traffic. No measurable request-path cost beyond standard controller dispatch. The scaling concern is architectural, not operational: ADR actions have a natural tendency to accrete business logic, so enforce a boundary rule (actions orchestrate, domain owns logic) before the pattern spreads across dozens of endpoints.

Failure modes.

• Composer resolution failure on Laravel 10 — loud, immediate, easy to diagnose. Low severity.
• Silently stale pin on Laravel 10 — quiet, compounding, no signal until a fix is needed and unavailable. Highest-severity failure mode of this release; mitigate with an explicit pin and a tracked sunset date.
• Stub drift — generated code written against older conventions diverges from current stubs. Medium severity, presents as codebase inconsistency and review friction.
• Generator collisions — running the new command where files exist; depends on overwrite behavior. Low severity if verified in the spike.
• PHP version floor conflict — if the 7.x line raised its PHP requirement, apps on 8.1 will fail resolution. Verify before pinning.

Ramp-up. Low. A Laravel-fluent developer is productive in roughly half a day; the cost is learning the team's ADR conventions, not the package. That makes this cheap to pilot on one service and cheap to abandon if conventions don't stick — both favorable properties for a first adoption decision.

Recommendation. Adopt 7.1.0 on Laravel 11/12 services; hold Laravel 10 services at ^7.0 with a tracked sunset. Treat the annual Laravel-major dependency bump as planned work rather than a surprise, and invest in stub publication and convention documentation up front — that, not the install, is what determines whether the package earns its place.