- What is alt-three/locker used for?
- Alt Three Locker is a driver-based lock manager for Laravel applications. It provides a manager that resolves pluggable lock drivers, a service provider, and a facade over the container so you can acquire and release locks through a consistent API. It is not a feature flag package despite some descriptions; treat it as a locking abstraction for legacy Laravel stacks.
- How do I install alt-three/locker?
- Install it with Composer using composer require alt-three/locker inside an application whose PHP and Laravel constraints match the package. Because the repository is archived and the last release was in 2020, expect resolution to succeed only in legacy constraint sets. Run composer why-not alt-three/locker before design work to confirm compatibility.
- Which Laravel and PHP versions does alt-three/locker support?
- The package was last released on 2020-07-25 and the repository is archived, so support likely stops around PHP 7.x and Laravel 7 or 8. Always verify the composer.json illuminate/* and PHP constraints against your actual runtime. Any mismatch is permanent because there is no upstream maintainer to patch it.
- Is alt-three/locker still maintained?
- No. The repository is archived and the last release was in 2020, so there is no active upstream support or issue history to rely on. Packagist shows zero dependents, meaning there is effectively no field validation. If you adopt it, every defect and compatibility problem becomes your responsibility.
- How does alt-three/locker compare to Laravel's Cache::lock?
- Laravel has included native atomic locks since 5.6 through Illuminate\Cache\Lock, Cache::lock(), and the LockProvider contract. Locker duplicates that core primitive behind its own manager and drivers. On Laravel 6 or newer, using Locker means maintaining a parallel implementation of a correctness-critical framework feature rather than filling a gap.
- Can I use alt-three/locker on Laravel 8 or newer?
- It is not recommended. The archived 2020 release likely targets PHP 7.x and older Laravel versions, so Composer resolution may fail on modern stacks. Even if it installs, you would be gating correctness-critical locking behavior on an unmaintained library. For Laravel 8 and newer, use framework-native locks behind an internal interface instead.
- What lock semantics should I verify before adopting alt-three/locker?
- Confirm whether you need blocking locks or try-locks, bounded lease or TTL behavior, owner-token-verified release, reentrancy, and fairness. Also determine whether execution is single-host or multi-host, because file or array drivers may be unsafe across multiple hosts. These requirements decide whether Locker's drivers are admissible at all.
- How should I test locking behavior if I use or migrate from alt-three/locker?
- Build behavioral tests for contention, TTL expiry, crash release, and non-owner release before trusting any lock implementation. If you are migrating, introduce an internal LockService interface, delegate to Locker first, then swap the delegate to native Laravel locks and run the identical suite for parity. In that path Locker serves as an executable behavioral spec, not a runtime dependency.
- What are good alternatives to alt-three/locker?
- Use Laravel's native atomic locks through Cache::lock() and the LockProvider contract, ideally behind your own LockService interface so drivers and semantics stay swappable. Choose Redis or database-backed locks based on whether you run single-host or multi-host. If you need Locker's design, harvest it as a reference for an internal abstraction rather than installing the archived package.
- What risks come with using an archived lock manager in production?
- Locking failures often appear as silent data incidents such as duplicate charges, double-sent emails, or corrupted aggregates rather than exceptions. An unmaintained library gating that boundary is a standing liability with no upstream escalation path. A lock manager abstraction can also create false confidence if the underlying file or array driver is unsafe across hosts.