- What is imanghafoori/eloquent-relativity used for in Laravel?
- It lets Eloquent models relate to each other through a generic, string-keyed relatives relation instead of hard-coding model class names inside methods like hasMany(Comment::class). You register a key-to-class map and call relTo('comments') to attach, detach, and query arbitrary model connections. It is aimed at decoupling modules, package-per-domain layouts, and DDD-style bounded contexts where one module should not import another module's model classes. It adds indirection that is usually not justified for conventional CRUD applications.
- How do I install eloquent-relativity in a Laravel app?
- Install it with Composer using composer require imanghafoori/eloquent-relativity. Laravel package auto-discovery should register the service provider, and you can publish the configuration if the package exposes one. Before committing, confirm the supported Laravel and PHP versions against the package's test matrix and CI evidence.
- Which Laravel and PHP versions does eloquent-relativity support?
- The expected envelope is Laravel 9, 10, and 11 with PHP 8.1 or newer, but this should be confirmed against the package's CI before adoption. The last release noted in the assessment is April 2024, and Laravel major-version compatibility beyond the current release is unproven. Because the package is upstream of nothing, you are the only one who will feel a break when Laravel changes.
- Does eloquent-relativity work with with(), whereHas(), withCount(), and other native Eloquent features?
- The package is intended to return relation instances that behave like native Eloquent relations, so methods such as with(), whereHas(), and withCount() should work if that holds true. The assessment flags this as something to verify empirically rather than assume, especially for hasManyThrough and polymorphic relations. Test the exact query patterns your application uses before relying on the package.
- How do I decouple Eloquent models across modules with eloquent-relativity?
- Replace hard-coded model class references in cross-module relationship methods with stable string keys and calls to relTo(). Register the key-to-class map in a service provider or configuration file so one module resolves another module's model without importing its class. Convert boundary-crossing relations first because those carry the decoupling value, and keep intra-module relations native because they gain nothing from the indirection.
- Can I use eloquent-relativity alongside normal Eloquent relationships?
- Yes, native and relative relations can coexist on the same model, which makes incremental adoption realistic. You can keep ordinary hasMany, belongsTo, and morph relations for relationships inside a module and use relTo() only where a module boundary must be crossed. This lets you convert domain by domain without a big-bang release.
- What are the production and maintenance risks of eloquent-relativity?
- The dominant risk is bus factor: the package has a single maintainer, around 148 stars, zero dependents, and a last release in April 2024. The indirection can defeat IDE navigation, Larastan and PHPStan return-type inference, IDE Helper generation, and tools that reflect on relationship return types. Key typos become runtime failures rather than static-analysis failures, which is a real regression in defect-detection posture. Mitigate by wrapping relTo in a project-owned trait and by covering relative relations with tests.
- How does eloquent-relativity affect Larastan, PHPStan, IDE Helper, and admin panels like Filament or Nova?
- Because relationships are resolved through string keys instead of direct class references, the indirection can defeat IDE navigation and static-analysis return-type inference. Tools that reflect on relationship return types or introspect model classes, including admin panel resources, query-builder packages, and API-doc generators, may be affected. Verify against your actual Larastan level, IDE Helper setup, admin panel resources, factories using for(), and route model binding or policy auto-discovery. Polymorphic relations and packages performing instanceof checks on relation objects are the highest-probability breakpoints.
- Can I replace eloquent-relativity later if I change my mind?
- Exit cost depends on how many files reference relTo, so the practical approach is to introduce it behind a deliberate seam. Wrap relTo in a project-owned trait so the vendor dependency is one file deep and replaceable with a thin internal wrapper. Count the references and test the wrapper before rolling the pattern out widely.
- Does eloquent-relativity support polymorphic relations and Relation::enforceMorphMap?
- The package introduces its own key-to-class mapping, while Laravel's Relation::enforceMorphMap is a separate morph mapping, so the key question is whether the two conflict in your application. The assessment flags polymorphic relations as a high-probability breakpoint that must be verified empirically. Test polymorphic relations and any package that performs instanceof checks on relation objects before adopting the package broadly.