- What is jetbrains/phpstorm-attributes used for?
- It provides official PHP 8 attribute classes such as Deprecated, ArrayShape, ObjectShape, Immutable, Pure, ExpectedValues, NoReturn, and Language that PhpStorm uses for richer completion and analysis. It is a metadata-only, dev-time package with no service provider, config, or runtime behavior in a Laravel app. Use it as IDE hints or as a resolved class reference for other analysis tools and editors.
- How do I install jetbrains/phpstorm-attributes in a Laravel project?
- Run composer require --dev jetbrains/phpstorm-attributes. No configuration, migrations, or code changes are required. It installs under require-dev and autoloads only in development, so commit the updated composer.json and composer.lock.
- Does jetbrains/phpstorm-attributes work with Laravel?
- Yes, but there is no Laravel framework integration to configure; it simply supplies attribute classes for IDE and static-analysis use. It requires PHP 8.0+ attribute syntax, which in practice means Laravel 9 and later for most teams. It does not interact with Eloquent, the container, queues, or the HTTP lifecycle.
- Do I need this package if I already use PhpStorm?
- Not usually, because the attribute classes are bundled with PhpStorm 2020.3 and later. Add the Composer package when other tools, editors, or CI jobs need resolved class references to avoid Class not found noise. It is most useful in multi-IDE teams or monorepos where not everyone runs PhpStorm.
- Does PHPStan or Psalm understand these attributes?
- PhpStorm understands these attributes natively, but PHPStan and Psalm do not without a bridging extension. Without a bridge, CI provides no enforcement and the attributes act as IDE-only documentation. Decide explicitly whether they are IDE hints or CI-enforced contracts before adopting them broadly.
- Is jetbrains/phpstorm-attributes safe to use in production?
- It is intended as a dev-only dependency, so the attribute classes are normally absent from the production autoload graph. Do not reflect on these attributes at runtime in production, because those classes may not exist there. Treat them as static-analysis metadata, never as runtime behavior.
- Can I use ArrayShape and ObjectShape for runtime validation?
- No, these attributes are metadata for IDE completion and static analysis, not validators or serializers. Runtime reflection over them can fail outside development because the package is dev-only. Use real validation, DTOs, or serialization logic for runtime enforcement.
- How do I prevent Class not found errors from PhpStorm attributes in CI?
- Add jetbrains/phpstorm-attributes as a dev dependency so the class names resolve for contributors and tools that inspect them. This fixes class resolution but does not make PHPStan or Psalm enforce the attribute semantics without a bridge. Configure the bridge or accept that the attributes remain IDE-only hints.
- What are the risks of using ArrayShape and ObjectShape annotations?
- They are hand-maintained type assertions that can silently drift when the underlying array or object shape changes. Once stale, they can produce confidently wrong completions and warnings, which is the main long-term quality risk. Review annotations when shapes change and consider CI enforcement if drift should fail builds.
- Is jetbrains/phpstorm-attributes maintained, and is there an alternative?
- It is an official JetBrains project under Apache-2.0 whose behavior is effectively a specification, so supply-chain risk is low and it is not practically substitutable. Version skew is possible between the IDE-bundled attributes and the Composer-pinned package when JetBrains adds or changes attributes. Dependency counts can be misleading because require-dev usage is often excluded.