- Is incompass/timestampable-bundle compatible with Laravel 10 and 11?
- It is not a Laravel package and declares no Laravel support; it is a Symfony bundle built for Doctrine ORM. Composer may install it in a Laravel 10 or 11 project, but it will not integrate with Eloquent. Only consider it if your Laravel app already runs Doctrine through a bridge and you have verified the Symfony and Doctrine versions.
- How do I install incompass/timestampable-bundle?
- Install it with Composer using composer require incompass/timestampable-bundle. In Symfony, register the bundle in your kernel and configure your entities with the provided marker interfaces, traits, and attributes or annotations. In Laravel, installation alone is not integration: you would also need a working Doctrine ORM setup and listener registration outside the bundle's Symfony conventions.
- Does this package work with Laravel Eloquent models?
- No. Eloquent already provides timestamps, created_at and updated_at handling, and Model::withoutTimestamps(), so the problem this bundle solves does not exist for standard Eloquent models. The bundle hooks Doctrine lifecycle events such as prePersist and preUpdate, not Eloquent events. For Eloquent, use native timestamps, an observer, or a trait with booted model hooks instead.
- Is it compatible with Doctrine ORM 3 and current Symfony versions?
- Doctrine ORM 3 changed listener signatures, and the package's supported Symfony, Doctrine ORM, and PHP constraints are not evidenced in the assessment. Confirm Composer resolution and listener interfaces against your installed versions before adopting. Any signature or bundle-registration mismatch should be treated as a stop sign, not a small patch.
- How do I configure createdAt and updatedAt fields on an entity?
- Configuration is attribute or annotation driven through marker interfaces and traits, and the bundle uses Doctrine event listeners to populate fields on persist and update. You mark the entity properties you want managed and let the listener handle the rest. Check whether the trait declares the properties or expects you to define them, because getting that wrong can cause property-already-defined or no-mapped-field errors.
- Does the bundle update timestamps on bulk DQL or bulk UPDATE queries?
- No. Doctrine lifecycle listeners do not fire on bulk operations, so bulk DQL or bulk UPDATE statements will bypass the timestamp listener and can leave updatedAt silently stale. This is a known failure mode you must design around. If you use bulk paths for affected entities, update timestamp columns explicitly in those queries.
- How should I test that automatic timestamping works?
- Write an integration test that persists a new entity and asserts createdAt is set, then updates the entity and asserts updatedAt changes. Use a real Doctrine entity manager against a test database rather than mocking the listener behavior. Also test any bulk DQL or bulk UPDATE paths separately, because listeners do not fire for those operations.
- What are the best alternatives for automatic timestamps in Laravel?
- For Eloquent, use native timestamps and created_at and updated_at, with Model::withoutTimestamps() when you need to suppress them. If you need custom behavior, a trait with booted hooks or a model observer is typically under a day of work and fully owned by your team. For Doctrine inside Laravel, a small custom Doctrine event listener is usually a better fit than adding an unmaintained Symfony bundle.
- Is incompass/timestampable-bundle production-ready and actively maintained?
- The assessment reports 0 stars, 0 dependents, and no evidence of license, CI, coverage, or release cadence, which is weak adoption signal. The namespace and repository mismatch suggests an internal extraction or vendor fork rather than a maintained OSS product. Assume you own the code on adoption and confirm the license permits vendoring or forking before use.
- Does it support DateTimeImmutable and timezone-aware timestamps?
- The provided overview does not document DateTimeImmutable or immutable_datetime support, nor UTC-only or timezone-aware handling. Check the source and tests before relying on immutable timestamp fields. If you need immutable timestamps, plan to fork the listener or implement that behavior yourself.