Peskycmf Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel/PHP library that can be installed via Composer, so structurally it will drop into a conventional Laravel application (service provider registration, config publishing, facade/contract bindings assumed). However, the 1.0 release note is a maintenance-status declaration — "Not maintained anymore" — not a feature release. There is no evidence of new capability, no changelog of fixes, and no stated compatibility window. Architecturally it may still fit today's codebase, but it is now a frozen dependency: whatever Laravel and PHP versions it supports at 1.0 is the ceiling unless we fork.

Integration feasibility. Installation is trivially feasible (Composer require + provider registration). The real feasibility question is governance: adopting a package whose upstream has explicitly disclaimed maintenance requires an explicit exception to our dependency policy. For a greenfield or low-criticality internal tool, integration is a half-day of work. For anything customer-facing, payments-adjacent, or long-lived, feasibility is conditional on us accepting ownership of the code.

Technical risk. High and asymmetric. The failure mode is not "it breaks on install" — it is silent decay: a future Laravel major release changes a container, event, or query-builder behaviour, the package is not patched, and the breakage surfaces in our application. Security risk is the sharper edge: an unmaintained package will not receive advisories or patches for vulnerabilities in its own code or in its transitive dependencies. Composer audit will flag abandoned packages (composer audit reports abandoned packages as a distinct warning), which will block CI in many setups.

Key questions.

• Is there a maintained alternative that covers the same capability, and what is the switching cost?
• How deep is our coupling — config-only, or do we extend its classes and rely on its internals?
• What is the package's licence, and does it permit an internal fork and redistribution?
• Do we have the PHP/Laravel competence to own a fork, and who is that person?
• What is the actual blast radius: does it touch auth, payments, persistence, or only presentation/formatting?
• Is the 1.0 tag the last commit, or are there later commits on the default branch we could pin to?
• Does it appear in our dependency tree already, transitively, via another package?

Integration Approach

Stack fit. Composer-installable, Laravel service-provider conventions — fits the stack mechanically. Fit must be assessed per application, not globally: a package that is acceptable in a back-office reporting tool is not acceptable in an authentication or billing path. Classify each candidate integration by criticality before proceeding.

Migration path. Two viable paths, decided up front and recorded in the ADR:

1. Do not adopt. Preferred default. Identify the maintained alternative and absorb the (usually modest) incremental build cost.
2. Adopt with an ownership plan. Vendor the package (or fork to an internal namespace), pin the exact version, commit the lockfile, and assign a named owner. This converts an unmaintained dependency into an internally maintained one — legitimate, but it must be budgeted as such rather than treated as free.

If the package is already in the tree, the path is a containment plan: pin, isolate behind our own interface/adapter, and schedule replacement.

Compatibility. No stated support matrix for Laravel or PHP versions in the release notes. We must determine the supported range empirically from composer.json constraints and a smoke test on our current runtime, then treat that range as fixed. Add a CI job that fails if our Laravel or PHP version moves outside it — this is the tripwire that converts silent decay into a visible ticket.

Sequencing.

1. Confirm whether it is already present (direct or transitive) — this determines urgency.
2. Run composer audit and record the abandoned-package finding.
3. Spike: install in a branch, exercise the integration path, capture the supported version range.
4. Decision point with the alternative comparison in hand.
5. If adopting: vendor/fork, add the compatibility tripwire to CI, write the ADR, name the owner.
6. If replacing: wrap behind an internal adapter first so the swap is a one-line binding change, then replace.

Operational Impact

Maintenance. This is the dominant cost. "Not maintained" means we inherit every future bug, every framework-compatibility break, and every security fix. Budget it explicitly: even a small package typically consumes a few days per year in forced upgrades, plus unbounded effort at each Laravel major. Without a named owner this cost is invisible until it is an incident.

Support. No upstream support channel, no issue triage, no CVE response. Our support organisation cannot escalate. Any production issue traced to this package is resolved by our own engineers reading its source. This must be reflected in on-call expectations and in the severity matrix.

Scaling. Scaling risk is low in the horizontal sense — a PHP library rarely constrains throughput beyond what it does per request. The scaling constraint is temporal: the package does not scale across time, i.e. across framework and language upgrades. It also does not scale across teams, because the knowledge of its internals concentrates in whoever forked it.

Failure modes.

• Silent breakage on framework upgrade — highest likelihood, moderate detectability if the tripwire is in place, high cost without it.
• Security vulnerability with no patch path — low likelihood per package, severe impact; mitigated only by contained blast radius or replacement.
• CI/audit gate failure — immediate and visible; blocks deploys when composer audit or an SCA tool flags the abandoned status. Often the first symptom.
• Bus factor — the internal owner leaves; the fork becomes unmaintained a second time.
• Knowledge drain — no upstream docs updates, so our engineers' understanding diverges from any public references.

Ramp-up. Low to learn the public API, high to learn the internals. Onboarding a new engineer onto a maintained package is reading docs; onboarding them onto this one is reading the source. If we fork, add a short internal README documenting what we changed, why, and how to patch — that single artefact is the difference between a manageable fork and a future rewrite. Recommend treating the fork as a first-class internal library: owned repo, tests, changelog, and a review cadence tied to each Laravel major release.