Laravel Common Laravel Package

Product Decisions This Supports

• Build vs. buy for shared platform plumbing. Pijler/laravel-common is a candidate to absorb repeated Laravel boilerplate across services (queue/Horizon wiring being the visible surface here). The v0.11.0 change is small but directionally useful: HorizonQueue now resolves the default queue connection instead of an assumed one, which is exactly the kind of environment-specific coupling you want removed before standardizing a package across staging/production and multiple services.
• Standardization roadmap. If we run Horizon in more than one Laravel app, a shared queue abstraction reduces per-repo drift. This release is evidence the maintainer is tightening portability, a prerequisite for fleet-wide adoption.
• Risk posture / dependency policy. Version 0.x, small contributor base, ~14 PRs. That argues for a pilot, pinned-version decision rather than a platform-wide mandate. This release does not change that calculus.
• Behavioral risk review before rollout. Despite being labeled a refactor, switching to the default queue connection can change which connection jobs are dispatched to in any service that sets a non-default queue connection for Horizon. Treat as a config-sensitivity check, not a no-op, and validate in staging before upgrading.
• Not a feature bet. Nothing here expands the use cases the package covers; it improves correctness/portability of an existing component. Don't let it anchor a roadmap narrative.

When to Consider This Package

Consider it when:

• You operate multiple Laravel services with Horizon and want a single, maintained home for queue-connection resolution rather than copy-pasted config.
• You can pin the version and absorb occasional 0.x behavior shifts, with a staging gate before production.
• Your team already treats shared internal packages as owned infrastructure (someone reviews changelogs and upgrades deliberately).

Look elsewhere when:

• You have a single Laravel app — Laravel's native queue config and Horizon cover this without a dependency.
• You need vendor-backed support or an API stability guarantee; 0.x with a narrow contributor base does not provide either.
• A single refactor commit is your only signal of maintenance activity — insufficient evidence of a healthy release cadence or test coverage.
• You rely on a hardcoded/assumed Horizon connection today and cannot test the change; wait for a version that documents the migration explicitly, or read the diff and confirm the previous connection default.

How to Pitch It (Stakeholders)

Executives: A low-cost, low-risk utility library that could remove duplicated queue configuration across our Laravel services. Latest release (v0.11.0) is a small internal fix making its Horizon queue component respect each service's default queue connection. Recommendation: no platform commitment yet — pilot in one non-critical service, pin the version, and revisit at 1.0 or when we have two or more validated adopters.

Engineering: v0.11.0 changes HorizonQueue to use the default queue connection instead of a fixed one. It's framed as a refactor, but it is a runtime behavior change anywhere the default differs from the previously assumed connection — verify dispatch targets in staging. Package remains pre-1.0 with limited maintainer bandwidth, so pin the version and review diffs on upgrade. Adopt if we want a shared home for Horizon/queue wiring; skip if only one app needs it.