Weave Code
Annotations Pack Laravel Package
symfony/annotations-pack
Symfony annotations-pack is a Composer metapackage that pulls in the libraries needed to use annotations in Symfony applications, chiefly doctrine/annotations. It simplified dependency setup during the Symfony 3.4 to 4.x transition.
A pack for the Doctrine annotations with cache
Frequently asked questions about Annotations Pack
- Is symfony/annotations-pack a Laravel package?
- No. It is a Composer metapackage of type symfony-pack built for Symfony Flex, and it ships no PHP code, no service provider, no config file, and no Laravel package-discovery entry. Installing it in a Laravel app is a no-op: Composer resolves it without error, but nothing registers an annotation reader for you. Laravel has no equivalent of the Flex pack mechanism, so the pack model has no real analogue outside Symfony.
- What does symfony/annotations-pack actually install?
- Its entire payload is a require block, chiefly doctrine/annotations plus a cache implementation, published with permissive wildcard constraints. There is no source code to autoload and no bootstrapping logic. Everything you actually need, meaning an AnnotationReader, a cached reader, and a PSR cache pool, has to be wired by your own application code.
- Why doesn't composer require symfony/annotations-pack give me working annotations in Laravel?
- Because a metapackage only pulls in dependencies; it does not register services. In Symfony a recipe declares the capability and Flex installs the pack, but in Laravel nothing interprets the symfony-pack type. You still have to register an AnnotationReader or a cached reader in a service provider and point it at a cache. The install succeeding is a false positive for feasibility.
- How do I use Doctrine annotations with a cache in a Laravel application?
- Require doctrine/annotations directly with an explicit version constraint, then bind a cached AnnotationReader in a service provider. Supply a PSR-6 cache pool, since doctrine/annotations 2.x expects PSR-6 while Laravel's Cache repository is PSR-16, so a bridge is typically required. Finally, configure a writable path such as storage/framework/cache/annotations and make sure permissions hold on read-only container filesystems.
- Do the wildcard version constraints in symfony/annotations-pack cause problems?
- Yes, this is the main technical risk. Packs are published with wildcard requirements, so a routine composer update can silently move doctrine/annotations 1.x to 2.x and doctrine/cache 1.x to 2.x. Those 2.0 lines removed the Cache interface and switched to PSR-6, which is a dependency-graph-breaking change. Because the pack gives you no version lever, you end up adding explicit requires or conflicts anyway, and the pack becomes pure overhead.
- Will symfony/annotations-pack conflict with laravel-doctrine or gedmo/doctrine-extensions?
- It can. Pinning doctrine/cache transitively through a metapackage you do not control is a classic way to deadlock resolution against laravel-doctrine, gedmo packages, or an existing symfony/cache install. Check whether your composer.lock already constrains doctrine/cache or psr/cache before adding anything. In practice, require doctrine/annotations with an explicit constraint rather than routing through the pack.
- Are annotations still recommended, or should Laravel developers use PHP 8 attributes?
- PHP 8 attributes are the forward path: annotation-based metadata is deprecated, and Symfony removed annotation support in its 7.x line, which makes these packs legacy artifacts. If inherited code or a third-party bundle forces annotations, isolate that dependency and plan the migration. Adopting annotations today means committing to a stack you will have to move off within your planning horizon.
- Which Laravel and PHP versions does symfony/annotations-pack support?
- The pack itself declares no Laravel constraint, because it is a Symfony Flex artifact that does not know Laravel exists. Real compatibility is decided by doctrine/annotations and your PHP version, so verify against the doctrine/annotations release line you actually need. Since the pack's requirements are wildcards, Composer may resolve a combination you did not intend.
- Does symfony/annotations-pack register anything with Laravel package discovery?
- No. It has no extra.laravel.providers entry and no service provider class, so Laravel's discovery mechanism has nothing to find. Compare that with a first-party Laravel package that ships a provider and config file. Anything annotation-related in your app must be bootstrapped by a provider you write yourself.
- Who manages the annotation cache lifecycle in a Laravel deployment?
- You do, because the pack provides no warmup, invalidation, or deploy hooks. You need to choose a cache path, make it writable at build or deploy time, and clear it whenever annotation classes change. On read-only or containerized filesystems this is a common source of production failures, so settle ownership before rollout.
Weaver
How can I help you explore Laravel packages today?