Sulu Shared Tools Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for internal scaffolding. A 0.2.0 release that ships shared Traits, Interfaces, EventListeners, and Services is a convention-layer package, not a feature. It answers "do we hand-roll our cross-cutting base classes in every Laravel app, or standardize on one?" — a decision that typically costs 2–4 engineer-weeks to make in-house and is otherwise invisible on a roadmap.
• Platform standardization / multi-app consolidation. If the portfolio has more than one Laravel service, this is a candidate to reduce duplicated boilerplate (event handling, service-layer contracts, shared behavior via traits). The PM value is fewer divergent patterns across teams, not new user-facing capability.
• Onboarding and time-to-first-PR. Shared interfaces and base services shorten the path from "new hire" to "merged PR" by removing the "how do we do X here" conversation. Treat as a developer-experience line item with a measurable proxy (time to first merged PR, PR review cycles).
• Roadmap timing signal — not a feature bet. At 0.2.0 the package is pre-stable. It belongs in an enabling track (internal tooling, starter kit, template repo), not in a customer-facing commitment or a launch narrative. Do not let it consume roadmap capacity reserved for differentiators.
• Not supported: any decision that assumes API stability, LTS guarantees, or a maintained migration path. There is no evidence of that in this release.

When to Consider This Package

Consider it when:

• You maintain two or more Laravel/PHP services and are already paying a real tax for inconsistent service layers, event listener patterns, or duplicated base traits.
• You have an internal starter kit or template repo and want a single vendored source of truth for these base classes rather than copy-paste across repos.
• Your team is comfortable pinning a 0.x dependency and treating upgrades as scheduled engineering work rather than automatic composer update drift.
• The consuming code is internal or low-blast-radius — internal admin tools, back-office services, non-customer-facing APIs.

Look elsewhere when:

• You need production stability or a support contract. 0.x semantics mean breaking changes between minor versions are expected and legitimate. That is not a criticism of the package; it is a fact about the version number.
• The requirement is a single app. Shared-class packages earn their keep through reuse; with one consumer you are adding a dependency edge for no consolidation benefit — keep the classes local.
• Your need is already covered by the framework or a mature package. Laravel's own foundation classes and established packages (e.g. spatie/laravel-package-tools for package scaffolding) cover adjacent ground with longer track records. Overlap here should be assessed before adoption, not after.
• You cannot yet see the actual API surface. This release note lists class categories only — no signatures, no contracts, no migration notes. Adopting before inspecting the source means adopting on faith.

Adoption gate before any commitment: read the source for these four class types, confirm the interfaces are the ones you'd actually implement, and confirm the traits don't impose hidden coupling (constructor assumptions, container resolution, static state). That review is the real decision input; the release note is not.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small internal-engineering dependency that standardizes repetitive plumbing across our Laravel services — shared interfaces, base services, reusable traits, and event listeners. It does not add customer-facing features and should not be sold as one. The upside is reduced duplicated code and faster onboarding across multiple services; the cost is a pre-1.0 dependency we must pin and upgrade deliberately. Recommendation: adopt only inside internal tooling with a pinned version and a named owner, revisit at 1.0. If we have a single Laravel service, decline — the reuse case doesn't exist yet.

For engineering: The 0.2.0 release exposes four categories of shared classes — traits, interfaces, event listeners, and services. That is a convention layer, so the questions that matter are: does the interface set match our service-layer contracts, do the traits hide container or constructor assumptions, and what is the upgrade cost when 0.3.0 changes signatures? Assign an owner to read the source and write a one-page verdict before we take the dependency. Pin the version explicitly, avoid ^ ranges on 0.x, and do not let it leak into customer-facing code paths until it reaches 1.0 or we fork and own it.

For product/roadmap: Timebox this as an enabling task, not a feature. Success looks like fewer duplicate base classes and a shorter onboarding path — measure with time-to-first-merged-PR and count of duplicated scaffolding files, not with user metrics. Flag that the current evidence base is thin: a single release note describing class categories, with no changelog history and no prior assessment. Treat any adoption recommendation as provisional pending a source review.