- Can I use tempest/clock in a Laravel application?
- tempest/clock is a first-party component of the Tempest framework, not a Laravel package. It ships with no ServiceProvider, no extra.laravel auto-discovery block, no facade, and no Laravel-facing contract, so Laravel will not wire it for you. You can install it as an unmanaged library, but you would need to bind it into Laravel's container yourself. For most Laravel teams, adopting the pattern or using Carbon is a better fit.
- Does tempest/clock support Laravel 10, 11, and 12?
- There is no declared Laravel integration or Laravel version support in this package. Its design assumptions are Tempest's: constructor injection through the Tempest container, discovery-based wiring, and sibling tempest/* packages. Whether it happens to run on a given Laravel and PHP version depends on its Composer constraints, not on tested Laravel compatibility. Do not assume Laravel 10, 11, or 12 support without verifying the package yourself.
- How do I install tempest/clock with Composer?
- You would install it with composer require tempest/clock, but Laravel will not auto-discover any service provider or configuration. You would need to register a binding manually and alias any interface you want to inject. Before committing, run composer show --tree tempest/clock to see whether it pulls in Tempest support packages or container contracts.
- Does tempest/clock implement Psr\Clock\ClockInterface?
- This must be verified from the source before any commitment. A PSR-20 implementation is portable and can be swapped for symfony/clock or your own clock; a bespoke interface is not. Laravel applications usually already have symfony/clock and PSR-20 transitively through the Symfony console and HTTP stack. If the package uses a custom contract, its value drops further for Laravel.
- How do I freeze time in Laravel tests without tempest/clock?
- The idiomatic Laravel approach is Carbon::setTestNow() or Carbon::withTestNow(), which most Laravel test suites already use. Illuminate\Support\Facades\Date also fronts Carbon for app-level overrides. For a stricter boundary, bind Psr\Clock\ClockInterface to a FrozenClock or MockClock in a small service provider. Either path avoids adding a zero-adoption dependency for a cross-cutting concern.
- Is tempest/clock safe to use in production Laravel applications?
- The technical risk is high: the package has zero stars and zero dependents, is pre-1.0, effectively has a bus factor of one, and publishes no security policy. It is also unmonitored from a supply-chain perspective, with no dependency bot or advisory feed signal. The concern is not that the code is bad, but that an every-request time abstraction is being sourced from a package with no downstream usage to learn from.
- What are the best alternatives to tempest/clock for testable time in Laravel?
- Laravel already has three overlapping options: Carbon::setTestNow() and Carbon::withTestNow(), symfony/clock with Psr\Clock\ClockInterface, and the Illuminate\Support\Facades\Date facade. The recommended alternative is a pattern transplant: reimplement a small Clock interface in your app against PSR-20, with SystemClock and FrozenClock implementations. That typically takes roughly 50 to 150 lines and gives you a Laravel-native provider with no Tempest dependencies.
- Does tempest/clock pull in the Tempest framework or container?
- This is the critical question and must be answered with composer show --tree tempest/clock before any adoption. If the component depends on tempest/support or Tempest container contracts, adapting it to Laravel collapses into vendoring a foreign framework's kernel. In that case, the adapter path is a hard no. Only proceed if the component is genuinely standalone.
- How do I mock or fake the clock in Laravel feature tests?
- Use Carbon::setTestNow() for most tests, or bind a FrozenClock implementation of Psr\Clock\ClockInterface in Laravel's container for a stricter boundary. Ensure the clock is reset between tests so time-dependent assertions do not leak state. If you transplant the pattern, keep separate SystemClock and MockClock classes and document the reset behavior.
- Is tempest/clock actively maintained and does it follow semantic versioning?
- The package is pre-1.0 and has no documented semver support window, so breaking changes should be expected. It is effectively maintained by the Tempest core team with no external contributors of record, which gives it a bus factor of one. Before relying on it, check commit activity in the last six months and whether the maintainers state any stability commitment.