jbzoo/event
A lightweight event dispatcher for PHP from the JBZoo toolkit, with simple listener registration, priorities, and subscriber support. Works standalone or alongside other JBZoo packages to decouple and extend application logic.
This release is a packaging-driven major with no stated public API change, so the primary TPM concern is ecosystem compatibility rather than feature adoption. The effective breaking change is the raised minimum runtime to PHP 8.3 and the coordinated jbzoo/* dependency floor of ^8.0.
Architecture fit: Suitable for Laravel/PHP services already standardized on PHP 8.3+ and willing to upgrade the jbzoo/* dependency set in lockstep. No API change lowers application-code integration risk, but the PHP baseline shift affects deployment architecture and CI.
Integration feasibility: High for modern Laravel stacks on PHP 8.3 or 8.4. Lower for apps still on PHP 8.2 or earlier, or apps with other dependencies pinning incompatible jbzoo/* versions.
Technical risk: Moderate. Risks are dependency-resolution conflicts from the ^8.0 inter-package constraint, mixed jbzoo/* major versions, and environments not yet on PHP 8.3. CI coverage across PHP 8.3/8.4/8.5 is positive, but Laravel-version compatibility is not stated in the release notes.
Key questions:
jbzoo/* package in our dependency graph available at ^8.0?jbzoo/* upgrade required, or can packages move independently?Stack fit: Best fit for Laravel applications already on PHP 8.3+ with dependency hygiene that allows coordinated package upgrades. It is a poor immediate fit for PHP 8.2 environments or teams unable to align the broader jbzoo/* set.
Migration path: Treat this as a platform/dependency migration, not an application-code migration. First upgrade runtime images and CI to PHP 8.3+. Then update this package and all related jbzoo/* dependencies together to ^8.0. Run the full Laravel test suite and dependency-resolution checks before merging.
Compatibility: Application-level compatibility should be low-risk because no public API change is declared. Runtime and dependency compatibility are the real gates: PHP <8.3 is unsupported, and mixed jbzoo/* majors may cause Composer conflicts or inconsistent behavior.
Sequencing:
jbzoo/* constraints.^8.0 availability for every required jbzoo/* package.Maintenance: The PHP 8.3 baseline reduces support burden over time and aligns the ecosystem on a single major line. Maintenance risk comes from lockstep jbzoo/* upgrades and keeping internal runtime images current.
Support: Support policy should explicitly state PHP 8.3+ and jbzoo/* ^8.0. Teams on PHP 8.2 need a documented upgrade path or must remain on the prior major. Clarify whether Laravel support is version-bounded and whether PHP 8.5 is considered production-ready or CI-only.
Scaling: No direct scaling impact is indicated. The change is packaging/runtime compatibility, not throughput or architectural behavior. Operational scaling concerns are limited to fleet-wide PHP runtime upgrades and dependency rollout coordination.
Failure modes: Most likely failures are Composer resolution conflicts, mixed jbzoo/* majors, CI/runtime PHP mismatch, and production hosts still on PHP 8.2. Because no public API change is declared, runtime dependency failures are more probable than application-code failures.
Ramp-up: Low for developers already on PHP 8.3+, mainly lockfile and dependency review. Higher for platform teams needing fleet-wide PHP upgrades, CI image changes, and coordinated multi-package releases. A short runbook covering PHP baseline validation, jbzoo/* alignment, and rollback to the previous major is recommended.
How can I help you explore Laravel packages today?