Decorator Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-cutting decorators (logging, caching, feature flags, tenancy): this package is a compile-time attribute-driven decorator wiring layer. It supports a decision to standardize on declarative attributes rather than hand-written service decoration, which reduces boilerplate in service providers and makes decoration auditable at the class level.
• Framework investment / portability: v1.2.3 is a Symfony bundle (yceruto/decorator-bundle). If your roadmap is Laravel-first, this is not a direct dependency decision — it is a signal about the underlying PHP attribute-decorator pattern. Treat it as prior art for whether to adopt a similar internal convention or a Laravel-native equivalent.
• Upgrade and maintenance risk budgeting: this release is a single, scoped fix — a namespace correction on the Compound decorator attribute. No API changes, no deprecations, no behavioral changes to runtime semantics. It does not create an upgrade task, but it does confirm the maintainer is active.
• Release cadence as a health signal for dependency review: one-commit patch releases on a small package are a proxy for low-maintenance, low-blast-radius adoption — useful input for your quarterly dependency review and for whether to vendor or pin.

When to Consider This Package

Adopt (or evaluate further) when:

• You are on Symfony and want attribute-based decorator composition without writing compiler passes by hand.
• Your team already uses PHP 8 attributes as the configuration surface for DI concerns, and consistency matters more than framework-native purity.
• You want a small, single-purpose, low-transitive-dependency package rather than a framework-bundled solution.
• The Compound decorator specifically matches a use case where multiple decorators must be applied as one declaration — verify against your version, since this patch exists precisely because that attribute's namespace was wrong.

Look elsewhere when:

• You are on Laravel. A Symfony bundle's extension points (kernel, bundle registration, compiler passes) do not map cleanly onto Laravel's container. Building on this in a Laravel codebase means fighting the framework boundary — prefer Laravel's own contextual attributes/binding, a plain middleware/pipeline pattern, or a small in-house decorator resolver.
• You need documented upgrade guarantees, LTS coverage, or a security response process — this package does not advertise one.
• The decoration graph is dynamic at runtime (config-driven, per-tenant). Attribute-based decoration is a compile-time construct; dynamic wiring belongs in config or a registry.
• Adoption is broad enough that a one-line namespace fix landing as a patch release would be better handled by your own pinned fork or internal shim.

Release-specific read: v1.2.3 is a non-breaking correctness fix. No migration work, no feature to schedule, no deprecation to plan around. If you are already on v1.2.x, bump at your normal cadence; if you pinned the Compound attribute namespace directly in app code, verify you were not relying on the previous value.

How to Pitch It (Stakeholders)

For executives (one line): This is a routine maintenance release of a small open-source PHP decorator package — no new capability, no breaking change, no action required beyond a standard dependency bump; it is not a Laravel-native library, so it is not on our critical path.

For engineering: v1.2.3 fixes the namespace of the Compound decorator attribute — a compile-time wiring bug, not a runtime one. Upgrade is low-risk and should ride the normal patch cadence. Two things to confirm before we formalize a dependency: (1) whether we are standardizing on attribute-based decoration at all, and if so whether that belongs in Laravel's native container attributes rather than a Symfony bundle; (2) whether anyone has hardcoded the old Compound namespace. Recommendation: treat as informational, not a roadmap item — revisit only if we commit to the attribute-decorator pattern as a team convention.