Weave Code
Common Laravel Package
canyongbs/common
canyongbs/common is a shared Laravel/PHP utility package from Canyon PBS, bundling common helpers, support classes, and conventions for reuse across applications. It helps reduce duplication and standardize project foundations. Install via Composer.
canyongbs/common is a shared utility package for Laravel/PHP projects, providing a consistent foundation of common code used across CanyonGB applications and packages. It helps reduce duplication by centralizing reusable helpers and framework integrations.
- Reusable helper functions and support utilities
- Shared traits and base classes
- Laravel service provider integration
- Composer-ready package structure
- Lightweight, dependency-conscious design
Frequently asked questions about Common
- What is canyongbs/common and what does it do?
- canyongbs/common is a first-party Canyon GBS shared foundation package for Laravel applications. It bundles common helpers, utilities, and base functionality such as service providers, model traits, and testing scaffolding used across Canyon GBS products. It is a horizontal dependency rather than a framework-level one, and its adoption and documentation are limited outside the Canyon GBS ecosystem.
- How do I install canyongbs/common in a Laravel app?
- Install it with Composer using composer require canyongbs/common in a Laravel application. The 2.43.0 release surface is low-risk and requires no application code changes, migrations, or config changes. Because the package is intended for Laravel apps already aligned with Canyon GBS conventions, install it in a non-production branch first and run your full test suite.
- Which Laravel and PHP versions does canyongbs/common support?
- The package targets Laravel applications on PHP 8.x and assumes Composer. The changelog excerpt does not publish a full version matrix, so confirm the exact illuminate/* constraints in the package's composer.json against your app's Laravel version before requiring it. If you are on an older Laravel or PHP version, test the bump in a branch rather than assuming compatibility.
- Is canyongbs/common safe to use in production Laravel applications?
- For 2.43.0 the technical risk is low: there are no runtime API removals, migrations, or config changes, and the only semantic item is a documentation-level deprecation of a Pest Livewire helper. The source-map-js bump is a front-end build-time transitive dependency and is unlikely to change generated assets in a user-visible way. Residual risk is indirect, from a fast-moving dependency graph and active CI reshuffling you do not control.
- What changed in canyongbs/common 2.43.0?
- Version 2.43.0 deprecates the Pest Livewire helper in the package's test guidance, speeds up CI, and includes two Dependabot dependency bumps: source-map-js 1.2.1 to 1.2.2 and GitHub Actions group updates. There are no public PHP API changes or config changes called out. The release is toolchain- and pipeline-adjacent rather than runtime-facing.
- What is the Pest Livewire helper deprecation in canyongbs/common?
- It is a documentation and convention-level deprecation, not a runtime API removal. Stop writing new tests against the deprecated Pest Livewire helper, grep your suite for existing usages, and size a refactor on the maintainers' timetable. The changelog excerpt does not name the replacement helper or a removal date, so ask the maintainers whether removal is planned for 2.44 or 3.0 and re-evaluate when 2.44.0 ships.
- Do I need Pest and Livewire to use canyongbs/common?
- The package assumes a Pest-based test suite with Livewire coverage, so teams already on that stack get the most value from its testing scaffolding. PHPUnit-only teams or apps without Livewire front ends can largely ignore the deprecated surface, though they can still consume the package's helpers and base functionality. Treat the Pest requirement as a convention rather than a hard runtime dependency, and verify what is actually required in composer.json.
- Should I constrain canyongbs/common to ^2.43 or stay on ^2.42?
- Constrain to ^2.43 only if you want the CI improvements; otherwise a ^2.42 floor with a lockfile update is sufficient for the same runtime behavior. Bump in a non-production branch and run the full suite to confirm no test-tooling fallout from the deprecation advisory. If you reuse the package's workflow templates, check that its GitHub Actions group bumps do not collide with your own pinned action versions.
- Is canyongbs/common a transitive dependency I should track?
- It depends on how it entered your dependency tree. Run composer why canyongbs/common or inspect composer.lock to see whether it is a direct dependency you deliberately adopted or a transitive one pulled in by another Canyon GBS package. That determines whether you track its releases at all; if it is transitive, follow the parent package's version constraints rather than pinning it yourself.
- How actively maintained is canyongbs/common, and are there alternatives?
- It is first-party Canyon GBS code with visible, PR-linked changelog entries and named contributor review, which is a reasonable supportability signal. Releases are frequent (2.42 to 2.43 in short order) and Dependabot-heavy, so expect routine bump PRs, and a small maintainer surface area is the trade-off on issue response times. The repository does not name direct alternatives; teams outside the Canyon GBS ecosystem typically rely on Laravel's own support package, community utility packages, or internal shared packages instead.
Weaver
How can I help you explore Laravel packages today?