Common Laravel Package

Getting Started

canyongbs/common is a shared Laravel foundation package: the traits, base classes, helpers, and config defaults that Canyon GBS products have in common. Day-to-day, you treat it as an internal utility dependency — you use what it gives you instead of re-writing it, and you read its changelog before you bump it.

Install and confirm what you got:

composer require canyongbs/common:^2.43
composer show canyongbs/common          # confirm installed version
php artisan about                        # confirm the provider was discovered

Package discovery should register the service provider automatically. If the repo ships publishable config, tags, or migrations, publish once and commit the result:

php artisan vendor:publish --provider="CanyonGBS\Common\CommonServiceProvider"
php artisan config:clear

Where to look first — in this order:

1. src/ — this package's public API is its source. There is no meaningful hosted documentation, so the trait and class list under src/ is your real reference. Skim the directory tree before writing anything; five minutes here saves you from reimplementing a helper that already exists.
2. config/ — anything tunable. Publish and commit it, then treat it as application configuration.
3. CHANGELOG.md / release notes — the release cadence is high and mostly chores, so the changelog is the fastest signal of what actually matters. For 2.43.0 specifically: the only semantically meaningful entry is deprecating the Pest Livewire helper in test guidance. Everything else is CI speed work and Dependabot bumps. No API changes, no migrations.

First use case: pick one model or service in your app that duplicates logic you suspect the package already provides. Swap in the package trait or helper, run your existing test suite against it. That validates the integration in isolation — one class — before you adopt the package more broadly. Don't start by applying traits across a dozen models.

Implementation Patterns

Compose, don't inherit. If the package ships model or service concerns, apply them as traits on your own classes rather than extending package base classes:

use CanyonGBS\Common\Concerns\SomeBehaviour; // verify the exact namespace in src/

class Widget extends Model
{
    use SomeBehaviour;
}

If you need to override part of the behaviour, put your override in a local trait that uses the package trait, and apply the local one. A minor bump can then change the package internals without silently clobbering your override — and you get one obvious file to review when something changes.

Wrap static helpers behind a thin app-level adapter. Shared utility helpers are typically static, which makes them hard to mock and easy to scatter across a codebase. A single App\Support\Common class with one method per helper you actually use buys you two things: testability (you can bind a fake), and greppability (grep -r "CanyonGBS\\\\Common" app/ gives you a complete inventory of your coupling). That inventory is what you check against each release note.

Configuration over patching. Anything exposed via published config should be set there. Never subclass or copy-modify a package class to change behaviour — with a release cadence this high, a copied class is stale within weeks.

Act on the test-guidance deprecation now, incrementally. 2.43.0 deprecates the Pest Livewire helper in the documented guidance — nothing in the code breaks today. The cheap response:

1. Grep the test suite for usages to size the work.
2. Write all new Livewire tests against Livewire's own Livewire::test() instead of the package helper.
3. Backlog the existing tests for conversion, and convert opportunistically as you touch them.

Avoid a big-bang rewrite; there's no removal date announced yet, and the incremental path means the eventual removal is a non-event.

Pin to ^2.43 and batch upgrades. Given the changelog is dominated by dependency bumps and chores between minors, floating the minor and updating monthly is reasonable. Read each changelog before the bump — the one-line "deprecate X" entry is exactly what gets lost in a bulk composer update.

Lift the CI patterns if they fit. 2.43.0 includes CI speed improvements. The workflows in .github/workflows/ — cache keys, job parallelisation, action version pinning — are usually directly transferable. Treat them as reference, not as something to inherit wholesale (see gotchas).

Gotchas and Tips

• The 2.43.0 change is documentation-only. If you skim the release and assume code moved, you'll burn time hunting a diff that doesn't exist. The action item is updating internal test-writing guidance, not code.
• Dependency bumps in the changelog aren't your dependency graph. source-map-js and the GitHub Actions group updates are build-time/toolchain concerns. No action on your side unless you reuse the package's workflow templates.
• Config caching is the classic trap. Publish config, then wonder why changes do nothing — bootstrap/cache/config.php is stale. Run php artisan config:clear after publishing or editing.
• Diagnose "undefined helper" before reading stack traces. php artisan about shows discovered providers; composer show canyongbs/common confirms the version. Most "the package isn't there" problems are a stale autoloader — composer dump-autoload fixes them.
• Never edit vendor/. If an extension point is missing, write a local trait wrapper or decorator. Patches vanish on the next composer update, and with this release cadence that's a matter of weeks, not months.
• Static helpers + lazy config resolution can behave differently in queues. If a helper returns different values in php artisan tinker versus a queued job, check config caching and whether the job worker booted before your config change — before blaming the package.
• Track the Pest helper's removal. The deprecation implies a removal path. Note it in your upgrade log so the next major doesn't arrive as a surprise test-suite failure.
• Small maintainer surface area. This is first-party Canyon GBS code with PR-linked changelog entries and named reviewer — good signal — but a small team means issue triage and security response times are a dependency you're accepting. For anything load-bearing, keep your own wrapper so you can patch around an upstream delay.
• The source is the documentation. With sparse external docs, when in doubt read the trait you're about to use, top to bottom, before you use it. It's usually 50 lines and answers the question faster than any search.