Shared Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-cutting shared code. The only real decision this package informs is whether to centralize common utilities, DTOs, config conventions, and service wiring into one Composer dependency versus maintaining them per application. That is a classic internal-platform decision, and it recurs for every team that has copy-pasted a helper twice.
• Framework strategy — and this is the decision it actually forces. The package is a Symfony bundle (*-bundle, Symfony conventions), being evaluated against what is described as a Laravel/PHP estate. A Symfony bundle is not a drop-in Laravel package: service providers, auto-discovery, config publishing, and facades do not carry over. So the first PM decision is not "adopt or not" but "is there a Laravel consumer for this at all, or are we a mixed-framework shop where a Symfony bundle serves only the Symfony services?" Adoption is a non-starter for Laravel-only apps unless someone bridges it.
• Roadmap sequencing for an internal platform. If we do have Symfony consumers, adopting a shared bundle is the cheapest way to stop duplication spreading before it hardens into divergent per-app behavior. That argues for adopting early, at small scale, rather than after five apps have each grown their own version of the same code.
• Vendor and maintenance risk acceptance. Three GitHub stars, an unelaborated changelog, and a single apparent maintainer make this a "convenience dependency with no support contract." That is a legitimate product decision (accept low-cost, low-support tooling for non-critical-path code), but it must be made explicitly and scoped — not discovered later when the maintainer goes quiet.
• Pin-and-audit as a policy precedent. The release history offers no enumerated changes for v2.1.2 — only a compare link. That means we adopt a process, not just a package: diff review on every bump, patch releases included. Setting that precedent here pays off on every future dependency.

When to Consider This Package

Consider it when all of the following hold:

• The consuming applications are Symfony, or we have a genuine mixed-framework estate where the Symfony services need this shared layer. For Laravel-only apps, look elsewhere or budget for a bridge/adapter — this is the primary disqualifier.
• The shared code is stable, low-churn domain logic — DTOs, utility services, config conventions. It is a poor fit for anything on the auth, payments, or PII path, because there is no SLA, no security advisory process, and no backport guarantee.
• Our consumer count is small (roughly three to five). Deploy fan-out is the hidden cost: every release must be bumped, tested, and deployed across every app, for changes none of them requested. At fifteen consumers this becomes a recurring tax that needs a named owner and a monthly bump window.
• We are prepared to fork if necessary. The mitigation for single-maintainer abandonment is a documented internal fork right — the ability to patch without waiting on upstream.
• We can verify the diff and constraints before merging: composer.json ranges for php and the relevant framework packages, whether it publishes migrations (migration-timestamp interleaving can deadlock deploys in apps with long migration histories), and whether it does anything at boot.

Look elsewhere when:

• The applications are Laravel-only — the integration cost likely exceeds the duplication it saves.
• The package would land on the request path of every consumer. Blast radius is the dominant risk: a regression here fails every app simultaneously and identically, so detection depends entirely on our test coverage, not theirs.
• We need vendor accountability — a support contract, security advisories, or a second maintainer. Three stars and silent patch releases are consistent with a hobby-scale project.
• The candidate code is already trivial. If the shared surface is a handful of helpers, a small internal package we own is cheaper to reason about than an external dependency we must audit on every bump.

How to Pitch It (Stakeholders)

One line: A small MIT-licensed shared-code bundle that could remove duplication across our services — but only if we're a Symfony shop, and only as a convenience dependency we're prepared to own.

For executives: This is a low-cost, low-support library. The license is permissive, the integration is a Composer pin, and there is no purchase or contract. The real cost is not money — it's coordination: every release must be rolled across every app that uses it, and there is no upstream support or security process to lean on. We should adopt it only for stable, non-critical shared code, and only after confirming it actually fits our stack.

For engineering: The package is a Symfony bundle, so treat framework fit as the gating question, not a detail — verify composer.json constraints against our PHP and framework matrix before any work is scheduled. Mechanically the bump is trivial; the discipline is the deliverable. One PR per app, lockfile plus composer why output only, never batched with feature work, so a regression bisects cleanly to the bump. Roll the lowest-traffic consumer first, hold several days in production, then fan out oldest-framework-first.

Recommendation to carry into the room: Do not approve broad adoption on this evidence. Approve a time-boxed spike in one Symfony consumer — diff review, constraint check, and a one-page consumer guide (what's public API, what's internal, how to bump) — and revisit with that write-up in hand. The package is cheap to adopt and expensive to adopt casually; the tribal knowledge of which classes are safe to extend currently lives nowhere, and that gap, more than the code itself, is the thing we'd be buying into.