Laravel Perpage Resolver Laravel Package

Technical Evaluation

Architecture fit

• Release 2.0.0 is a hard compatibility boundary, not an incremental upgrade. It simultaneously cuts three axes: API surface (backwards-incompatible changes), runtime (PHP 8.0 only), and framework (Laravel ^8 / ^9 only).
• The package now pins consumers to a narrow platform window. Any application on PHP 8.1+ or Laravel 10+ is outside the supported envelope, so this package becomes a constraint anchor that can block wider platform upgrades.
• The stated rationale for bumping illuminate/database to ^8 is security-driven, which is a legitimate and positive signal — but the dependency is declared as a floor, not a range. Understanding whether it resolves on Laravel 9 (where the framework ships illuminate/database ^9) is the single most important architectural unknown.

Integration feasibility

• Upgrade is feasible only where the host app is already on PHP 8.0 and Laravel 8 or 9. For those apps, adoption is low-effort and security-positive.
• For apps on Laravel 10/11 or PHP 8.1+, the release is effectively unusable until the package widens constraints — the correct decision is to stay on 1.x (accepting the unresolved illuminate/database security exposure) or replace the package.
• The BC break implies consumer-side code changes. Scale of that work is unknown without a changelog enumerating removed/renamed APIs.

Technical risk

• High — platform lock-in: PHP 8.0-only support means PHP 8.0 reaches end-of-life (Nov 2023); the package is pinning consumers to an unsupported runtime for security patches.
• High — dependency resolution: an illuminate/database ^8 requirement on a Laravel 9 app is a potential Composer conflict, or a silent duplicate/downgrade of framework components. Must be validated, not assumed.
• Medium — BC surface unknown: no migration guide, deprecation list, or removed-method inventory was provided. Risk of a partially-applied upgrade is real.
• Medium — security trade-off inversion: 1.x carried a database-layer security concern; 2.0.0 fixes it but strands the runtime. Teams on PHP 8.1+/Laravel 10+ now face an unresolvable trade-off between the two.

Key questions

1. Is "supported ONLY PHP 8.0" a minimum (>=8.0) or an exact pin (8.0.*)? This changes the risk profile materially.
2. What is the actual illuminate/database constraint string — ^8 only, or ^8|^9? How does it resolve on Laravel 9?
3. Is there a published BC-break inventory / upgrade guide, and what's the expected remediation effort per consumer?
4. Is a 2.1.x with PHP 8.1/8.2 and Laravel 10/11 support on the maintainer's roadmap, with dates? Without this, 2.0.0 is a dead-end branch.
5. What is the CVE/severity behind the illuminate/database bump, and does it affect 1.x consumers who cannot upgrade?
6. Is the package actively maintained (release cadence, issue responsiveness, maintainer count)? "PHP 8.0 only" in a post-8.0-EOL world is a maintenance-health signal.

Integration Approach

Stack fit

• Fits: PHP 8.0, Laravel 8.x or 9.x, Composer 2, apps with no near-term framework upgrade planned.
• Does not fit: PHP 8.1/8.2/8.3 estates, Laravel 10/11, or any org with a standing policy against EOL runtimes. For those, treat 2.0.0 as not applicable and escalate the replacement decision.

Migration path

1. Inventory first. Enumerate every service consuming the package at 1.x, with its PHP and Laravel version. This alone likely splits the estate into "can upgrade" and "cannot."
2. Validate resolution before code changes. On a representative Laravel 9 app, run composer require --dry-run in a branch to confirm the illuminate/database constraint resolves cleanly. Do not schedule migration work until this passes.
3. Confirm the BC-break surface. Obtain or reconstruct the removed/changed API list; grep consumer code against it to size the change.
4. Upgrade in a canary service (lowest-traffic, PHP 8.0, Laravel 8/9) behind the existing test suite; verify database-layer behavior specifically, since that's where the dependency changed.
5. Roll forward, not back. Because 1.x is the security-exposed branch, the fallback is "stay on 1.x with a documented accepted risk," not "upgrade then revert."

Compatibility

• Hard gates: PHP version, Laravel major version, illuminate/database resolution. All three must pass; any failure means stop.
• Downstream constraint propagation: if the consuming app is itself a package or shared library, the 2.0.0 constraints propagate to its consumers. Check for second-order lock-in before adopting in shared code.

Sequencing

• Phase 1 (now): inventory + constraint validation + obtain BC inventory. No production changes.
• Phase 2: canary migration on a qualifying service; document the concrete change set.
• Phase 3: migrate remaining qualifying services.
• Phase 4 (parallel, blocking): decide the disposition of non-qualifying services — hold on 1.x with accepted risk, or begin replacement evaluation. This is the decision with the longest lead time and should start in Phase 1, not Phase 3.

Operational Impact

Maintenance

• Net maintenance posture is mixed: the security fix is a genuine win, but the package now requires per-release compatibility babysitting against a narrowing platform window.
• Consumers on PHP 8.0 inherit EOL-runtime maintenance burden. Expect recurring security exceptions and audit findings, even though the package itself is clean.
• Budget ongoing effort to track whether the maintainer widens constraints; without that, the migration is a one-way door.

Support

• Supportability depends entirely on maintainer responsiveness. "PHP 8.0 only, Laravel ^8/^9" reads as a package tracking a specific downstream fork or a stalled maintainer — validate before relying on it.
• Internal support load: any 1.x consumer hitting the illuminate/database security issue now has no upgrade path if they're on PHP 8.1+/Laravel 10+. That's an escalation path to define before it's needed.
• No published migration guide means internal SMEs absorb the documentation cost.

Scaling

• Scales fine technically — a database-layer dependency bump doesn't change performance characteristics. No capacity work required.
• Organizationally it does not scale: each new service must be checked against three constraints, and the pool of qualifying services only shrinks over time as the org standardizes on newer PHP/Laravel. Plan for this package's footprint to contract, not grow.

Failure modes

• Composer conflict at install: illuminate/database ^8 cannot resolve on Laravel 9+ → upgrade fails at CI, blocking unrelated work if attempted on a shared branch.
• Silent component downgrade: resolution "succeeds" by pulling an older illuminate/database than the framework expects → subtle, hard-to-trace database-layer bugs in staging or production.
• Partial migration: BC break applied to some services only → inconsistent behavior and a split test/debug surface.
• Security gap persistence: services that cannot upgrade remain on 1.x with the unfixed database dependency, and this goes untracked because the 2.0.0 release created a false sense of "security resolved."
• Runtime EOL exposure: PHP 8.0 CVEs accumulate with no vendor patches; the app is secure at the package layer but exposed at the platform layer.

Ramp-up

• Low for engineering — a Composer bump plus targeted code edits, assuming the BC inventory is available.
• Moderate for the TPM: requires a cross-team inventory, an explicit accepted-risk record for non-qualifying services, and a replacement/hold decision with a review date.
• Recommend a time-boxed checkpoint (e.g. 90 days) to reassess maintainer roadmap. If no path to PHP 8.1+/Laravel 10+ emerges by then, reclassify the package as end-of-life and initiate replacement planning.