Common Laravel Package

Technical Evaluation

Architecture fit. canyongbs/common is a horizontal, first-party utility package for Laravel applications — shared traits, base classes, config defaults, and test conventions. It is not load-bearing: nothing in the package is required to build a Laravel app. Its fit is therefore organisational rather than technical. It scores well if we are building inside the Canyon GBS product family or deliberately want to inherit their conventions; it scores poorly as a general-purpose dependency, because we would be adopting one vendor's internal house style as our own.

Integration feasibility. Mechanically trivial: composer require canyongbs/common:^2.43, package discovery registers the service provider, publishable config (if any) lands via vendor:publish. Consumption is by trait composition and static helpers, both of which are easy to graft onto an existing codebase incrementally. The real constraint is not engineering effort — it is that there is no public API reference. Beyond the README and changelog, an engineer must read src/ to know what is actually available. Budget a discovery spike before committing to a scope.

Technical risk. Three risks dominate, and only one is about this release.

• Licensing. The repo is NOASSERTION on GitHub while the description explicitly states the software is copyrighted and trademarked by Canyon GBS Inc. That is a procurement and legal question, not an engineering one, and it gates everything else. Redistribution, modification, and derivative-work rights must be established in writing before this enters a production dependency graph.
• Bus factor. Two stars, no visible external consumer base, a small named maintainer group. There is no community fork to fall back on, no third-party tutorials, and no hiring pool that knows the package. If Canyon GBS deprioritises it, we own the code.
• Release velocity without signal. The 2.42 → 2.43 delta is Dependabot bumps plus a documentation-level deprecation. That is fine, but it means changelogs carry low information density and real API changes can hide in a crowded feed.

Key questions.

• What are the actual license terms, and do they permit our intended use, modification, and internal redistribution?
• Is this a direct dependency we chose or a transitive one pulled in by another Canyon GBS package? That determines whether we track it at all.
• Is the Pest Livewire helper deprecation advisory-only, or is removal scheduled for 2.44 or 3.0? We need a date to plan a test refactor against.
• Do we consume any of the deprecated helpers today? What is the named replacement?
• Who is the accountable owner on the Canyon GBS side, and is there any support commitment?

Integration Approach

Stack fit. Laravel with PHP 8.x, Composer, and — for the deprecated surface — a Pest test suite with Livewire coverage. Teams on PHPUnit-only testing or without Livewire can ignore the 2.43.0 deprecation entirely; they simply have less of the package's surface area to worry about.

Migration path. No migration is required to adopt 2.43.0. Adoption itself should be opt-in per helper, not a big-bang swap: pick one model or service that duplicates logic the package already provides, replace it with the package trait, and run the existing suite against it. That validates integration in isolation and gives a concrete data point for the go/no-go on broader rollout. The only standing action item is process-level — stop writing new tests against the deprecated Pest helper, and inventory existing usages.

Compatibility. Constrain to ^2.43 if we want the CI improvements; ^2.42 with a lockfile refresh is otherwise sufficient. Do not patch vendor/ — with this release cadence a patch survives weeks at most. Where the package exposes configuration, publish it, commit it, and treat it as app config. Where it exposes static helpers, wrap them behind a thin app-level adapter so they are mockable and the package reference stays greppable.

Sequencing for a TPM.

1. Legal/licensing clearance — hard gate, do this first, and do not start engineering until it clears.
2. Half-day discovery spike over src/ and config/ to produce an inventory of what we would actually consume.
3. Single-service pilot with the existing test suite as the acceptance test; define success criteria (lines of duplicated code removed, test pass rate, no behavioural drift) up front.
4. Grep for deprecated Pest Livewire helper usage and size the refactor.
5. Roll out to additional services only if the pilot clears its criteria; otherwise stop at the pilot and document why.
6. Set an explicit exit criterion — the conditions under which we fork, replace, or drop the package.

Operational Impact

Maintenance. Low per release, non-trivial in aggregate. Nothing in 2.43.0 touches runtime paths, so no monitoring, alerting, or runbook work is created. The ongoing cost is cadence management: batch upgrades monthly rather than per-release, and read each changelog rather than trusting the version bump — the one-line "deprecate X" entry is exactly what gets lost in a bulk composer update.

Support. First-party maintenance with PR-linked changelog entries and named reviewer involvement, which is a reasonable supportability signal. But there is no published SLA, no issue triage commitment, and no external community to absorb questions. We are effectively dependent on a small team's goodwill and priorities. That is acceptable for a convenience layer; it is not acceptable for anything we would call critical path.

Scaling. None. No runtime, query, caching, or queue implications in this release or in the package's stated scope.

Failure modes.

• Convention drift — our app and the package's testing/testing-guidance evolve apart, leaving stale tests that break on a future breaking release. Mitigation: incremental refactor of the deprecated helper now, tracked as backlog with an owner.
• CI coupling — if we reuse the package's GitHub Actions templates, upstream action bumps can break our pipeline with no change on our side. Mitigation: pin our own action versions; lift patterns, not files.
• Licensing surprise — discovery of restrictive terms after adoption forces a removal project. Mitigation: clear it before the pilot.
• Abandonment — with two stars there is no fork community. Mitigation: keep the package behind adapters and traits so a replacement is a swap, not a rewrite.

Ramp-up. Trivial for a Laravel/Pest engineer — one changelog read and the deprecation note. The non-obvious cost is discovery, because there is no API documentation; the half-day src/ inventory in the sequencing above is the realistic onboarding budget. Total engineering time for the bump plus helper inventory is roughly an hour; total time for a responsible adoption decision, including legal, is measured in days.