- How do I install saeedpooyanfar/laravel-annotation in a Laravel app?
- Install it with composer require saeedpooyanfar/laravel-annotation, then confirm whether the package ships a service provider with Laravel auto-discovery and a publishable config file. Point the resolver at the scan path you want it to inspect. The install is cheap, but the real work is deciding your cache-invalidation contract and who owns the scan path.
- Does laravel-annotation support Laravel 11, Laravel 12, PHP 8.3 and PHP 8.4?
- PHP attribute syntax is stable, but the Laravel-side coupling in this package, including service provider registration, cache facade usage and artisan commands, can break at major versions. The last release was April 2024 and there is no public evidence of it surviving a Laravel major upgrade. Verify the composer constraints against your locked Laravel and PHP matrix, ideally with a CI or throwaway upgrade branch, before adopting it.
- How do I define routes and metadata on controller methods with annotations?
- You place the #[Annotation] attribute on controller classes and methods, and the package resolver reads that declarative metadata off the class or method via reflection. Route registration or other behavior still comes from a layer that consumes the resolved metadata, so you keep the declaration close to the code and let one consumer act on it. Do not spread the attribute through domain code; consume it through a single internal resolver service.
- How is annotation scanning cached and how do I invalidate the cache?
- The caching contract is the key design decision with this package, so confirm where the cache is stored, how it is invalidated, and whether a warm or cache artisan command exists. Reflection directory scans are boot cost rather than request cost only when the results are cached. Pair the package with deploy-time warming so attribute scanning never happens per request.
- Is annotation scanning slow in production?
- Uncached reflection directory scans in a large application are a latency and memory hazard, especially on cold deploys. The package is fine in production only if you cache the resolved metadata and warm that cache during deployment. Treat scanning as a build or boot concern, not a per-request concern.
- What happens if an annotation key is misspelled or missing?
- There is no compiler-level validation, so a typo in an annotation key can fail silently or at runtime, potentially in a production path. Add explicit validation in the resolver seam you control and fail loudly on missing or unknown keys. Cover the common annotation shapes with tests so a bad key is caught before deploy.
- What does laravel-annotation give me over native ReflectionClass::getAttributes()?
- Native ReflectionClass::getAttributes() is built into PHP 8 and a small internal helper with a cached registry may cover around 80 percent of the value with none of the dependency risk. This package mainly adds a resolver and Laravel integration convenience around declarative metadata. Wrap it behind your own interface so you can swap to native reflection or another package with a single class change.
- How do I test annotation-driven routes and metadata in Laravel?
- Test through the resolver seam rather than asserting on raw attributes scattered through controllers. Use feature tests that hit the endpoints or actions produced by the metadata, plus unit tests that assert the resolver returns the expected metadata for a fixture controller. Include a test for a misspelled or missing annotation key so validation behavior stays explicit.
- Is saeedpooyanfar/laravel-annotation maintained and safe to use in production?
- It is a single-maintainer package with a last release in April 2024, roughly 17 stars and no downstream dependents, so abandonment is the highest risk rather than the API surface. There is no public evidence that it has survived a Laravel major upgrade. If you adopt it, plan to own it, fork it into your registry and pin the fork, treating upstream as reference rather than supply chain.
- How do I migrate off laravel-annotation later or wrap it behind my own interface?
- Adoption is additive, so the migration that matters is the exit path. Define your own interface such as MetadataReader on day one and let the package be one implementation behind it, with native reflection as the fallback backing implementation. That keeps #[Annotation] contained to a single seam and makes replacing or retiring the package a one-class change.