- What does happyr/annotation-warmer actually do?
- It pre-populates annotation and reflection metadata caches at deploy time so runtime readers skip parsing docblocks on the first request. It scans classes, primes a Doctrine-style annotation reader cache, and exposes a command meant for a build or release step. It does not run on the request path and does not ship a Laravel service provider.
- Is happyr/annotation-warmer a Laravel package?
- Not in practice. It is Symfony DI-oriented and compiles into or reads from a Symfony ContainerBuilder, with no Laravel service provider, config publish, facade, or Artisan command included. You would need to write the bridge yourself, typically a service provider plus an Artisan command or post-autoload-dump hook. Its fit in Laravel is contingent on doctrine/annotations being present transitively.
- How do I install happyr/annotation-warmer in a Laravel app?
- You can attempt a Composer require, but expect dependency resolution problems on Laravel 10 or 11 because the package likely pins symfony/console or symfony/framework-bundle to ^3.4 or ^4.x while Laravel requires symfony/console ^6.2. A replace or alias hack is a strong signal to stop. If you proceed anyway, you must add the service provider and deploy command yourself.
- Does it support Laravel 10 or Laravel 11?
- There is no official Laravel version support statement, and release 0.3.0 adds no Laravel integration. Composer constraints make Laravel 10 and 11 installs likely to fail outright. Treat any working setup as a custom fork that you maintain and pin.
- Why is my annotation cache still cold after running the warmer?
- A silent no-op usually means the cache keys the warmer writes do not match the keys your runtime reader reads. The command can succeed while the cache stays cold, giving you a false sense of coverage. You must validate key parity between the warming step and the production reader configuration.
- Does happyr/annotation-warmer work with PHP 8 attributes?
- No. Its reason for existing is docblock annotations via doctrine/annotations, not PHP 8 attributes. Attributes are instantiated lazily by the engine and need no warming. The package has no attribute-scanning warmup story and no evident PHP 8.1, 8.2, or 8.3 compatibility work.
- What happens with doctrine/annotations 2.0?
- doctrine/annotations 2.0 removes AnnotationReader, which is the component this package warms. The package's core use case is being deprecated out of the ecosystem, and 0.3.0 does not pivot to attribute scanning. Long term, plan to remove annotations rather than invest in warming them.
- Is the 0.3.0 config a stable contract?
- No. Release 0.3.0 removed default config values, which is a backward-incompatible change for anyone who relied on them. That is legitimate at 0.x under semver but means the config shape is not a stable contract. Pin the exact version you fork against and supply config explicitly.
- What are the alternatives for warming caches in Laravel?
- If you do not use Doctrine annotations, there is nothing to warm because Laravel core has no annotation reader. For Doctrine users, consider Doctrine's own cache warmers or Symfony's annotation cache warmer where applicable, and migrate to PHP 8 attributes where possible. For general Laravel deploy speed, use config, route, view, and event caching plus OPcache preloading instead.
- Should I use happyr/annotation-warmer in production?
- Only if your app loads doctrine/annotations in production, wraps the reader in a persistent cache pool, and has a large enough annotation surface that cold parsing is measurable. Those three conditions are unusual in a Laravel codebase. The package is pre-1.0, Symfony-coupled, undocumented, and carries high technical risk, so most teams should avoid it or vendor a small fork.