Annotations Pack Laravel Package

Product Decisions This Supports

• Dependency hygiene / build-vs-buy: This is not a buy decision — symfony/annotations-pack is a Composer metapackage containing no code of its own. It exists purely to pull in doctrine/annotations and symfony/cache together under Symfony Flex. Any "adoption" question collapses into "should we require two packages directly?" The answer is almost always yes, or neither.
• Legacy modernization sequencing: The only genuine product decision this informs is when to retire annotation-based configuration in favor of PHP 8 attributes. That's a roadmap item for a platform/upgrade epic, not a feature enabler.
• Compatibility surface for integrations: Relevant if you maintain or consume a bridge that still reads Doctrine annotations (e.g., laravel-doctrine ORM mappings, older validation/serializer metadata). The pack signals "this code path assumes annotations + a cache pool" — useful as a scoping signal, not a dependency to add.
• Support matrix / stated minimums: If your product publishes a compatibility matrix (PHP version, Symfony version, Laravel version), this package anchors you to a pre-attributes world. That constrains what you can claim to support.
• Does not support: any feature, pricing, packaging, or go-to-market decision. Zero value as a differentiator.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining an existing Symfony Flex application on a version line where annotations are still supported (Symfony ≤ 6.4-era behavior).
• You already depend on doctrine/annotations for real metadata (routes, ORM mappings, validation, serializer) and want the conventional cache-pool wiring with no manual config.
• You are explicitly in a freeze posture — stabilizing a legacy branch, not building forward.

Look elsewhere — or skip entirely — when:

• Greenfield. Use PHP 8 attributes. No reader, no cache pool, no runtime reflection parse cost.
• Symfony 7+. Annotation support has been removed from the framework; the pack is dead weight.
• Laravel-native work. Laravel does not use Doctrine annotations for routing, validation, or Eloquent. Its caching is Illuminate\Cache, not symfony/cache. This package is a foreign object in a Laravel app and will only appear via a Doctrine/ORM bridge — in which case require the bridge, not the pack.
• You just need the two libraries. composer require doctrine/annotations symfony/cache is strictly better: explicit, auditable, no abandoned middleman.
• Supply-chain sensitivity. Zero stars, zero dependents, abandoned upstream, and a nonzero install footprint is a bad ratio. A metapackage adds a trust boundary and a lockfile entry for something you can express in one line.

How to Pitch It (Stakeholders)

To executives: We evaluated symfony/annotations-pack and recommend against adopting it. It is a deprecated convenience wrapper for a technology the PHP ecosystem has already replaced — PHP 8 attributes superseded Doctrine annotations, and Symfony 7 removed annotation support outright. It contains no code, has no community adoption, and is not maintained. Adopting it would add a dependency we'd have to remove within a release or two, and would signal technical debt in our stack to anyone reviewing it. There is no product upside.

To engineering: It's a Flex metapackage: doctrine/annotations + symfony/cache, nothing more. If a legacy subsystem still requires an AnnotationReader, require those two packages directly and wire the cache pool explicitly — that's clearer, auditable, and doesn't route you through an unmaintained artifact. Treat this as a migration trigger, not a dependency: inventory where annotation metadata is still read, size the conversion to attributes, and put a date on removing the reader. For Laravel-side work, this package is effectively irrelevant — Laravel's routing, validation, and caching layers don't use it; if it shows up, it arrived via a Doctrine/ORM bridge, and the bridge is what we should be evaluating.