- What is teknoo/immutable and where does it fit in a Laravel application?
- teknoo/immutable is a small, framework-agnostic PHP library for building immutable objects, likely a trait or base class that blocks post-construction mutation plus an ImmutableInterface marker. In Laravel it belongs in the domain layer: DDD value objects such as Money, Email or DateRange, domain events, and command or query DTOs. It does not touch presentation, persistence or transport, so the blast radius of adoption stays limited to the classes you apply it to.
- How do I install teknoo/immutable with Composer?
- Install it with composer require teknoo/immutable. There is no service provider or config file to publish, so no Laravel registration step is needed. Check the require block of the tagged release first to confirm its PHP constraint matches your project before adding it to a Laravel 11 or 12 codebase.
- Does teknoo/immutable support Laravel 11, Laravel 12 and PHP 8.2 or newer?
- The package does not ship Laravel integration, so Laravel support mainly depends on the PHP constraint declared in its composer.json. Support for PHP 8.2, 8.3 and 8.4 is not verified in the available documentation, and stale version constraints are a common blocker during framework upgrades. Confirm the latest tag's requires and the CI matrix before committing.
- Should I use teknoo/immutable instead of PHP 8.2 readonly classes?
- On PHP 8.1 and later, readonly properties and PHP 8.2 readonly classes deliver most of this package's value with native IDE and static-analysis support and zero third-party surface. The library still makes sense if you are on older PHP versions or need enforced immutability on classes you cannot mark readonly. A fair evaluation is to implement the same value object twice, once with the trait and once as a final readonly class, then compare ergonomics, PHPStan output and serialization.
- Can I use teknoo/immutable with Eloquent models?
- Not recommended. Eloquent hydrates models by assigning attributes directly, and mutation guards built on __set, __unset or __clone trickery commonly fight that process and Laravel's casts pipeline. Keep the library out of models, form requests and anything the framework populates via reflection or mass assignment, and apply it only to hand-built domain objects.
- What API does teknoo/immutable provide: an interface, a trait, an abstract class, or withX clone helpers?
- The available signals point to post-construction mutation guards and an ImmutableInterface marker, possibly with clone-on-write withX() accessors. The exact surface is not well documented, so read the source, which is small, before designing around it. If withX() helpers are missing you will need to write your own clone-and-modify accessors.
- Does teknoo/immutable work with serialization, JSON encoding and queued jobs?
- Verify __serialize, __unserialize and __clone behavior early, because serialization is the usual breakage point for immutability libraries. This matters for queued jobs, cache payloads and API responses in Laravel. Write a test that round-trips a value object through json_encode and through the queue before relying on it in production.
- Is teknoo/immutable actively maintained and safe to use in production?
- Ecosystem validation is weak: roughly four GitHub stars, no known dependents, and it appears to be a single-maintainer project under the Teknoo organization with no LTS policy or paid support tier. Expect to read the source and own the risk yourself. Check the last commit date, open issues and whether tagged releases exist rather than depending on dev-main.
- Will teknoo/immutable conflict with spatie/laravel-data, symfony/serializer or PHPStan?
- Magic methods are the risk area, so test against spatie/laravel-data, symfony/serializer and any hydrator or object mapper you use before rolling it out. Static analyzers such as PHPStan and Psalm may need stubs or ignores for dynamic property guards. Isolating the package behind your own interface keeps any conflict inside the value-object layer.
- What are the alternatives to teknoo/immutable and how hard is it to migrate away later?
- The main alternative is native readonly properties and readonly classes, and on PHP 8.0 final classes with private constructors plus named static factories get you close. spatie/laravel-data and similar DTO packages cover parts of the same ground. To keep migration cheap, hide the package behind an interface your code owns, such as App\Domain\Contracts\ImmutableValueObject, and never expose Teknoo types in public signatures, so switching to native readonly becomes a per-class change.