- Can I use tbn/getter-trait-bundle in a Laravel application?
- Not as a Composer dependency. It is a Symfony bundle, so it expects bundle registration in config/bundles.php and the Symfony HTTP kernel lifecycle, neither of which Laravel provides. You can still vendor the underlying trait files into your Laravel codebase with attribution and own them internally, which is usually the right trade for a package this small.
- How do I install tbn/getter-trait-bundle?
- In a Symfony app, run composer require tbn/getter-trait-bundle and then register the bundle in config/bundles.php. Do not expect a Symfony Flex recipe given the package's adoption level. For Laravel, skip the Composer install and copy the trait source files into your project instead.
- Which Laravel and PHP versions does tbn/getter-trait-bundle support?
- There is no Laravel support to speak of, since this is a Symfony bundle rather than a Laravel package. Check the Symfony and PHP constraints declared in its composer.json and run composer why-not against your target versions before committing. Verify behavior on PHP 8.1+ if you rely on typed properties, constructor promotion, or readonly.
- Does tbn/getter-trait-bundle support typed properties, constructor promotion, and readonly properties?
- This is not documented and needs source review before you rely on it. Traits generally cannot redeclare properties that conflict with the consuming class, and readonly properties impose extra constraints on how accessors behave. Test on a scratch DTO with your exact PHP version before adopting it anywhere real.
- What happens if my class already declares a getter with the same name as the trait?
- Standard PHP trait collision rules apply if the trait declares real methods: you get a fatal error unless you resolve it with insteadof or an alias. If the package uses __call or reflection instead, behavior differs and is harder to reason about. Either way, add a collision test to your suite rather than assuming a silent skip.
- Is tbn/getter-trait-bundle safe to run in production?
- Supply-chain surface is small: MIT licensed, likely no network or filesystem code, and adoption is opt-in per class. The real risk is maintenance, not runtime — two stars, zero dependents, and a single maintainer mean no production validation signal. For Laravel production code, vendor the traits and own them rather than depending on the package.
- How does tbn/getter-trait-bundle interact with Doctrine, PropertyAccess, and ObjectNormalizer?
- Symfony components like PropertyAccess and ObjectNormalizer probe accessors reflectively, so the implementation matters. Real generated methods behave predictably, but magic __call-based getters can confuse normalizers, static analysis, and IDE autocompletion. Verify serialization and hydration behavior in a scratch Symfony app before wiring it into an existing pipeline.
- Is there a test suite or documentation for tbn/getter-trait-bundle?
- Documentation and community signal are effectively absent, so treat the repository itself as the specification. Check whether a test suite exists and how it covers edge cases like method collisions and typed properties. Also confirm the MIT license header is present in each source file, then budget time to write your own tests.
- What are good alternatives to tbn/getter-trait-bundle in Laravel?
- Laravel already gives you Eloquent accessors and attribute casting, and plain explicit getter methods are often clearer than trait magic. PHP 8.4 property hooks are another option if your runtime supports them. For DTOs, consider a small hand-written trait or an IDE-generated accessor set that you control.
- How do I remove tbn/getter-trait-bundle if I stop using it?
- Rollback is effectively zero-risk because adoption is additive. Delete the use SomeGetterTrait; lines from your classes and run composer remove tbn/getter-trait-bundle. There is no schema, config, or data migration to unwind, and your codebase stays valid without the package.