Getter Trait Bundle Laravel Package

Product Decisions This Supports

• Build vs. borrow for developer ergonomics. This package is a narrow convenience layer (trait-based getter generation for entities/DTOs and bundles). The real decision it informs is whether a 2-star, 0-dependent, single-maintainer utility belongs in our codebase at all — versus five minutes of IDE-generated accessors or native PHP constructor promotion.
• Feature velocity vs. boilerplate tax. If a roadmap item is blocked or slowed by repetitive accessor code across a large domain model, this could shave keystrokes — but only if the boilerplate is actually measurable. In PHP 8.1+ (readonly, constructor promotion), most of this is now a language feature, not a package need.
• Framework alignment check. Despite being framed as a Laravel/PHP package, this is a Symfony bundle (Bundle naming, Thomas Beaujean's ecosystem). If our stack is Laravel-first, adopting it means dragging in a bundle-style lifecycle that doesn't fit our conventions. That is a product/architecture decision, not just a technical one.
• DX tooling roadmap. A candidate to evaluate, timebox, or explicitly reject for the internal developer-experience backlog — with a written rationale so we don't re-litigate it next quarter.
• Dependency posture. Establishes whether we accept unmaintained, low-signal third-party code on a critical path. Adoption here sets precedent more than it buys capability.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony, not Laravel — the bundle integration is the only thing it does that a one-liner trait in our own src/Support folder doesn't do better.
• We have a concrete, measured boilerplate problem that survives PHP 8.1+ constructor promotion and readonly properties.
• The code sits in internal or non-critical paths with low blast radius (admin panels, internal DTOs, prototypes).
• We are willing to vendor or fork it. MIT license makes that cheap; we should assume we are adopting dead code we will own, because 2 stars / 0 dependents / single maintainer is not a support relationship.
• We are running a timeboxed spike where speed beats longevity.

Look elsewhere (or just write the trait ourselves in ~20 lines) when:

• We're greenfield on PHP 8.2+ or Laravel — the package solves a problem the language already solved.
• The code touches the domain model, billing, auth, or anything audited — supply-chain and compliance review will cost more than the boilerplate savings.
• We need vendor SLAs, security patching, or a maintainer who responds. There are no public dependents, which means no crowd-sourced bug discovery.
• The team's convention is IDE-generated or explicit accessors, in which case adoption fragments style for negligible gain.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a tiny developer-comfort utility that reduces boilerplate accessor code. It's free (MIT) and low-risk to trial, but it's unproven — two GitHub stars, no known dependents, single maintainer. It is not a platform bet and not on the roadmap. Recommendation: no budget, no procurement, at most a one-engineer, one-week spike on a non-critical module. If it doesn't clearly pay for itself, we write the twelve lines ourselves and move on.

To engineering: It generates getters via traits for Symfony entities/DTOs. It overlaps heavily with PHP 8.1 constructor promotion and readonly properties, so the honest pitch is "convenience if your codebase predates those features, and only in Symfony." Because it's MIT and trivially forkable, the right posture is: wrap it behind an internal convention so we can replace it, never sprinkle it through the domain model, and treat the maintainer as absent. If we adopt, we add a Support/ shim and a one-paragraph ADR recording why — and we revisit when PHP version or Symfony major changes.

Decision requested: Approve a scoped evaluation spike, or reject and standardize on native language features. My recommendation is reject for production, optional spike for internal tooling — the capability is real but small, and the dependency signal is too weak to justify a standing commitment.