Association Resolver Bundle Laravel Package

Product Decisions This Supports

• Feature feasibility for "attach anything to anything" requirements. The problem space this package addresses — resolving Doctrine entity associations dynamically from annotations rather than hardcoding them — maps to product features like comments, tags, attachments, audit trails, notifications, or activity feeds that must attach to heterogeneous entity types (orders, invoices, users, documents). If that requirement is on your roadmap, this is a reasonable reference architecture, not a dependency.
• Build vs. buy: this lands firmly on "build." Zero stars, zero dependents, zero opportunity score, and no ecosystem signal means there is no community to inherit bug fixes from. The package is a thin, single-maintainer Symfony bundle from an agency's internal toolkit. The cost of reimplementing the resolver pattern in-house is small — days, not weeks — and the cost of owning a fork is ongoing.
• Stack-fit decision, and this one is decisive. Despite being filed under PHP, this is a Symfony bundle, not a Laravel package. It ships a *Bundle class, DI extension, and Doctrine annotation-driven service wiring. If your product runs Laravel, adoption implies either a parallel Symfony service or a port; neither is justified for a 0-star dependency. Mark it as not adoptable in your technology radar and move on.
• Roadmap input on data modeling. The pattern argues for a generic association table (subject type, subject id, target type, target id, relation name) instead of per-feature pivot tables. That is a schema decision worth making deliberately at design time, because retrofitting polymorphic relations after three features have shipped their own pivot tables is expensive. Use this package as a prompt for that conversation, not as the implementation.
• Use-case scoping. Realistic internal consumers: a unified comment/attachment service, a generic audit log, a permission model that grants access to arbitrary records. Unrealistic consumers: anything on the critical path, anything multi-tenant-sensitive, anything requiring query performance at scale — dynamic annotation resolution typically produces N+1 queries or requires hand-tuned DQL.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony 2.x/3.x application with Doctrine annotations, and the annotation reader is already a hard dependency.
• You need generic entity association resolution and have no appetite to write ~200 lines of resolver plus a metadata driver yourself.
• The feature is internal, low-traffic, and non-critical — an admin tool, a reporting helper, a back-office annotation layer.
• You are prepared to vendor/fork it, pin the commit, and accept full maintenance ownership, including a migration path off Doctrine annotations before PHP 9 / Symfony 6+ removes them.

Look elsewhere — or build — when:

• You are on Laravel. Laravel's native polymorphic relations (morphTo, morphMany, morphToMany) solve this problem directly, are first-party, tested, and documented. There is no reason to reach across ecosystems.
• You are on Symfony 5.4+ or 6+/7+. Doctrine annotations are deprecated in favor of PHP attributes; bundle auto-registration conventions have changed; the annotation reader is a separate, sunsetting package. The package's core mechanism is on a deprecation track.
• You need maintained dependencies. Zero dependents means no one is filing issues, no one is patching CVEs, and no one has validated it against current PHP. Your security review will flag this as unmaintained and your SCA tooling will have nothing to compare against.
• You need performance guarantees. Annotation-driven dynamic resolution is a runtime metadata lookup. If the feature is user-facing and hot, model it explicitly.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source PHP library that solves a real modeling problem — letting one feature (comments, attachments, audit logs) attach to many different kinds of records without a new database table per record type. The pattern is sound and worth adopting; this specific library is not. It has no users, no maintainers beyond its originating agency, no security posture, and it targets a framework generation we are not on. Recommendation: adopt the pattern, implement it in-house on our own stack's native primitives. Estimated effort is measured in days, and it removes a permanent unmaintained-dependency risk from our supply chain.

To engineering: This is a Symfony bundle, not a Laravel package — it does not fit our stack. It solves generic Doctrine association resolution via annotations, which is the same shape as Laravel's morphTo/morphMany, so if the requirement is polymorphic relations, we already have a first-party answer. If the requirement is genuinely more dynamic than morph relations (named, runtime-configurable association types resolved from metadata), we should design a small internal resolver — a metadata registry plus an association table plus a scoped query builder — and cover it with tests. Do not add this to composer.json. If someone wants the pattern for reference, read it; don't depend on it.

One-line verdict: Steal the idea, skip the dependency — it's a Symfony-only, zero-adoption bundle whose core mechanism (Doctrine annotations) is itself deprecated, and our stack already has a native equivalent.