Symfony Commons Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. copy (copy wins): With 5 stars, a last release of January 2018, version 0.3, and no Laravel service provider, this is not a dependency decision — it's a pattern-sourcing decision. The PM call is "extract the idiom, don't composer require," which removes the maintenance liability entirely while capturing the value.
• Value object / domain-invariant conventions: The 0.3 release's assert() usage in value objects is a reusable convention for our own app/ValueObjects layer. This feeds a coding-standards decision: do we enforce invariants via assert() (dev-only, disabled in prod) or via exceptions that always fire? Product impact is real — silent invalid state is a data-integrity bug class.
• Observability strategy (Telescope / debug tooling): The "data collector works without Twig" fix is a design precedent for decoupling collection from presentation. If we are building or reviewing internal debugging panels, this is a cheap reference architecture: collectors return arrays/DTOs; the view layer renders.
• Roadmap input for a shared PHP domain package: If we run or plan any Symfony service alongside Laravel, this validates the pattern of a framework-agnostic domain package with per-framework wiring. That is a genuine architectural fork in the roadmap, not a library pick.
• Engineering quality-gate calibration: Functional tests around container wiring plus PHPStan level 4 is a usable (if modest) template for how we gate our own internal utility packages. It informs our "minimum bar for shared internal libraries" policy.
• Non-decision to document: A clear, defensible "no" on adopting a Symfony bundle in a Laravel codebase — useful precedent when similar packages surface and someone asks "why can't we just install this?"

When to Consider This Package

Consider mining it (patterns only) when:

• We are standardizing value objects and want a reference for invariant enforcement with a clear view on assert() vs. exceptions in production.
• We are building a debug/profiler surface in Laravel (Telescope, Horizon, custom panels) and want a small example of collector/presentation separation.
• We maintain or plan a Symfony service alongside Laravel and need a lightweight commons bundle for shared services — this is the only scenario where actual installation is on the table.
• We need a precedent for a framework-agnostic domain package consumed by two frameworks.

Look elsewhere when:

• The codebase is Laravel-only. The package will not auto-register, has no ServiceProvider, no facade, no config bridge, and installing it yields un-bootable classes. The effort is pure waste.
• Anyone proposes a "Laravel bridge" to make it work. Maintaining a bridge for a 5-star, dormant, pre-1.0 bundle is a negative-ROI project; we would own the integration and the upgrade path forever.
• We need production-grade guarantees: no LTS branch, no enterprise support, no evidence of backward-compatibility policy for 0.x, and dependency constraints pinned to PHP/Symfony versions from early 2018 that will almost certainly conflict with a current Illuminate graph.
• We want validation we can trust in production. assert() is disabled by default (zend.assertions=-1), so a value object relying solely on assertions is a dev-only guard, not a domain rule.
• We need long-term vendor stability. Last release 2018 means we would be adopting an effectively unmaintained artifact; if we need the code, we should fork or vendor the two or three classes we actually want, with our own tests.

Concrete adoption criteria (all must be true): a real Symfony runtime in our estate, a verified non-conflicting dependency graph, the specific classes proven framework-agnostic, and a decision on assertion-vs-exception in production. Absent any one of these, decline.

How to Pitch It (Stakeholders)

For executives — one paragraph: A small open-source PHP library surfaced as a candidate for our Laravel work. My recommendation is not to adopt it as a dependency. It is a Symfony bundle, last released in January 2018, with minimal community traction and no Laravel integration; forcing it in would create a permanent maintenance obligation with no offsetting benefit. However, it contains two genuinely useful engineering patterns — a clean way to enforce domain invariants in value objects, and a clean separation between data collection and rendering for debugging tools. I am recommending we extract those patterns internally at zero dependency cost. Net: no new vendor risk, no licensing cost, small but real quality gain, and a documented "no" that saves us from re-litigating this class of decision.

For engineering leadership: Treat this as a reference implementation, not a package. Two artifacts to read: the value-object assert() idiom (0.3 hardened it) and the DataCollector/ Twig-decoupling diff (the clearest signal in the release — it shows collection separated from presentation). Copy the collection/presentation split into any Telescope-adjacent work we do. Do not copy the assertion pattern blindly: PHP assertions are compiled out in production, so our house rule is exceptions for domain invariants, assert() only for developer sanity checks — and that rule should be written down as part of this evaluation.

For the requesting team: The honest answer is no with a caveat. If you need the behavior, spend a day porting the two or three classes you actually want into packages/ or app/ValueObjects with your own tests, and mirror the release's CI shape (functional tests on the wiring, static analysis on the public API). Note that PHPStan level 4 catches dead code and return-type mismatches — it is not a type-safety guarantee, so do not treat the upstream quality signals as stronger than they are. Pin nothing, because we are not installing anything.

Risk summary table for the decision log: