- What is sebastian/object-reflector used for in Laravel projects?
- It is a small dev/test utility that returns a flat name => value map of an object's properties, including inherited private and protected ones. In Laravel projects it is useful for programmatic assertions and custom debug output where dump() and dd() are not enough. It has no service provider, config, or container binding and is not a production platform component.
- How do I install sebastian/object-reflector in a Laravel project?
- Install it with composer require --dev sebastian/object-reflector. No PHP extensions are required, and it autoloads via PSR-4. If it is already present transitively through PHPUnit, a direct require makes intent explicit but can conflict with PHPUnit's version pin.
- Does sebastian/object-reflector work with Laravel 10, 11, and 12?
- It has zero framework awareness and does not conflict with Laravel 10, 11, or 12. Compatibility is driven by your PHP version rather than the Laravel version. Check your PHP and PHPUnit matrix before adding a direct constraint.
- Is sebastian/object-reflector already installed with PHPUnit?
- Yes, it commonly arrives transitively through PHPUnit via sebastian/object-enumerator. That means adoption may mean sanctioning direct use of an already-pinned package, not adding a new supply-chain node. Verify with composer show in your own project before deciding.
- How does object-reflector differ from PHP's native ReflectionClass?
- Native ReflectionClass requires visibility filtering and manual parent-chain traversal to collect all properties. object-reflector gives you one call that returns a flat map, with inherited members keyed as ParentClass::property. The trade-off is that key formatting and behavior are not a documented contract.
- Can object-reflector access private and inherited properties?
- Yes, it reflects inherited, private, and protected properties. Readonly properties are readable but not writable, and uninitialized typed properties, static properties, closures, resources, and cyclic graphs are edge cases to verify. Values are returned as-is, so avoid logging secrets or tokens.
- Should I use sebastian/object-reflector in production code?
- Generally no. It is intended for dev/test and local debugging, and reflection is slower than direct access while eroding encapsulation. A debug helper that logs private properties can leak tokens or closure internals into logs. Enforce test-only usage with PHPStan, PHPCS, Pest architecture expectations, or code review.
- What PHP and PHPUnit versions does sebastian/object-reflector support?
- The package tracks current PHP only, and its majors are version-locked to PHPUnit majors; for example v5.x drops PHP 8.2 and v6.x drops PHP 8.3. Confirm the exact matrix on Packagist before committing. A direct require-dev constraint can conflict with PHPUnit's pin and block a PHP downgrade or PHPUnit major bump.
- How do I test private properties with Pest or PHPUnit using object-reflector?
- Instantiate the object and pass it to the reflector to get a property map, then assert against the key. For inherited private properties, use the ParentClass::property key rather than naive string matching. Prefer this for programmatic assertions, not for human-readable dumps.
- What are the risks and alternatives to sebastian/object-reflector?
- Risks include version choreography with PHP and PHPUnit, production leakage if misused, undocumented key formatting, and a single-maintainer bus factor. Alternatives are native ReflectionClass plus a small helper, or Symfony VarDumper's dump() and dd() for readable output. Because the surface area is tiny, vendoring a replacement is feasible.