- How do I install klaude/eloquent-preferences in a Laravel app?
- Run composer require klaude/eloquent-preferences, then publish the package config and migration using Laravel's vendor:publish command and run php artisan migrate. After that, add the HasPreferences trait to the Eloquent models that should store preferences. Pin an exact package version because the package is pre-1.0 and minor releases may include breaking changes.
- Which Laravel and PHP versions does klaude/eloquent-preferences support?
- Do not rely on the release notes alone; inspect the composer.json constraints for illuminate/* and PHP before adopting it. The technical evaluation suggests a Laravel 8/9-era fit on PHP 8.0/8.1, while Laravel 10 and 11 support is unverified. Validate the package in a throwaway branch against your pinned framework and PHP versions, and do not work around conflicts with --ignore-platform-reqs.
- How do I add preferences to an existing Eloquent model?
- Add the HasPreferences trait to the model, which exposes a polymorphic preferences relation for that model. The package does not require a new column per preference, so you can store per-model key-value settings without schema churn. Keep preference validation, naming conventions, and access rules in your application layer.
- Does klaude/eloquent-preferences support typed preference values or casts?
- The package is primarily a raw key-value store, with typing, validation, defaults, and caching left to application code. You can cast values through model accessors, a wrapper service, or custom preference objects. Do not assume built-in cast support without verifying the package source and tests.
- Can I define default values for model preferences?
- Per-attribute defaults are not described as a built-in package feature, so implement fallbacks in your application code. A common approach is an accessor or service method that returns the stored preference when present and a configured default otherwise. This keeps default semantics explicit and testable in your domain layer.
- Is there built-in caching or eager loading to avoid N+1 queries?
- No built-in caching or eager-load guidance is called out in the package evaluation, so N+1 handling is the caller's responsibility. Eager load the preferences relation with with('preferences') where appropriate and layer application caching for hot reads. Benchmark your actual access patterns before assuming the polymorphic relation is faster than fixed columns or a JSON column.
- How does klaude/eloquent-preferences compare to spatie/laravel-settings or a JSON column?
- This package fits flexible, per-model, user-editable preferences where you want to avoid schema changes for every new setting. spatie/laravel-settings is often a better fit for typed application settings classes, while a JSON column or fixed columns can be simpler and faster for few, stable, hot-path preferences. Benchmark against your real read and write patterns before choosing.
- Is klaude/eloquent-preferences production-ready at version 0.6.0?
- Treat it as a pre-1.0 dependency: v0.6.0 can introduce breaking changes in minor releases, and the project has a single primary maintainer with thin test-matrix signals. Pin an exact version, run the migration and trait behavior in staging first, and put preference reads behind a feature flag if replacing existing settings. The blast radius is limited because the package performs no external I/O or credential handling, but you still need a maintenance and upgrade plan.
- How can I migrate existing settings columns to klaude/eloquent-preferences?
- Publish and run the package migration in staging first, then verify the polymorphic index and column types against your database engine. Use a dual-write window that writes to both the old columns and preferences, backfill historical rows, and read from preferences behind a feature flag. After a soak period, drop the old columns only when the rollback path can restore reads from the original source.
- Does klaude/eloquent-preferences include a test suite or CI matrix I can run?
- The evaluation flags thin CI coverage and low-fidelity release notes, so do not assume a complete Laravel/PHP test matrix. Check the repository for a test suite and run its documented test command, such as composer test or vendor/bin/phpunit, in a disposable branch. Add your own integration tests for preference reads, writes, defaults, and migration behavior before production adoption.