Common Laravel Package

Product Decisions This Supports

• Build vs. buy vs. inherit. canyongbs/common is first-party Canyon GBS software, so the real decision isn't "buy this package" — it's "do we standardize on Canyon GBS conventions, or do we own our own shared foundation?" This package is the cheap answer only if we're already inside that ecosystem. If we're not, the build cost of a thin internal utility package is likely lower than the cost of adopting someone else's conventions and roadmap.
• Platform consolidation. If we run multiple Laravel services with copy-pasted traits, base classes, and service-provider glue, this package directly attacks that duplication. That's a roadmap item with a clear, low-risk pilot: one service, one duplicated concern, validate with the existing suite.
• Testing and CI standards. The 2.43.0 release is almost entirely CI speed work plus a testing-convention deprecation. That's a signal the upstream team is actively investing in pipeline ergonomics — worth mining for our own CI templates even if we never adopt the runtime code.
• Deprecation-driven roadmap input. The Pest Livewire helper deprecation gives us a dated, concrete backlog item (inventory and migrate tests to Livewire::test()). That's a scheduling decision, not a feature decision — low priority, but it should exist in the backlog with an owner before a major removes it.
• Dependency governance. A frequently-released, Dependabot-heavy shared package implies a dependency graph we don't control. That's a policy question: do we track it as a direct dependency with a review step on each minor, or treat it as transitive and ignore it?

When to Consider This Package

Adopt when:

• We are building or maintaining Laravel applications within the Canyon GBS ecosystem, or integrating with their products, where shared conventions reduce friction more than they cost.
• We have demonstrable duplication across two or more Laravel services — the same model concerns, base service providers, or helper classes appearing in multiple repos.
• Our stack is already Laravel + Composer + Pest + Livewire. The package's value proposition and its testing scaffolding both assume this; a PHPUnit-only or non-Livewire front end gets little from it.
• We want a low-commitment trial: pin ^2.43, wire one concern into one model, run the existing suite. Reversible in an afternoon.
• We're specifically interested in lifting the CI workflow patterns — composer cache keys, parallel jobs, action pinning — which are useful independent of runtime adoption.

Look elsewhere when:

• We are not a Canyon GBS shop. The license is NOASSERTION, the copyright and trademark are asserted by Canyon GBS Inc., and the package is explicitly "custom software developed and used by multiple products at Canyon GBS." That's a governance question before it's a technical one — legal should confirm redistribution and modification terms before we build on it.
• We need vendor-backed SLAs or a public support channel. Two stars and a small maintainer team is a real bus-factor exposure for anything load-bearing.
• Our duplication problem is small or concentrated — a handful of helpers doesn't justify adopting an external convention set with its own release cadence.
• The roadmap depends on stability of the test tooling surface. The Pest Livewire helper is on a deprecation path; if our suite leans on it heavily, we're inheriting someone else's migration timeline.
• We need predictable, semantic-versioned API guarantees. The changelog cadence here is chores and dependency bumps between minors; that's healthy maintenance, but it's not a stability commitment we can plan a multi-quarter roadmap around.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk shared-utilities package from Canyon GBS that could let us stop maintaining duplicate Laravel plumbing across services. The 2.43.0 release changes nothing at runtime — it's CI improvements, dependency bumps, and a documentation-level deprecation in test guidance. There is no production risk and no migration. The decision to make is strategic, not technical: do we want to standardize on an external team's conventions and release cadence, or keep our foundation in-house? Before we answer, legal needs to review the license (NOASSERTION with asserted copyright and trademark).

For engineering: Consume via traits and composition, wrap package helpers behind an app-level adapter so they stay mockable and greppable, and set behavior through published config rather than subclassing. Pin to ^2.43, let minors flow, and read the changelog before each CI update. Budget roughly an hour for the bump plus an inventory of any deprecated Pest Livewire helper usage — migrate new tests to Livewire::test() now and refactor existing ones incrementally rather than waiting for removal. The real risk isn't this release; it's drift between our test conventions and the package's, and CI coupling if we inherit their workflow templates.

Recommendation: Run a one-service pilot — adopt ^2.43, replace one duplicated concern, run the full suite. In parallel, have legal confirm licensing terms and have an engineer size the Pest helper inventory. Decide on broader adoption only after both come back clean.