- What does salamwaddah/laravel-relation-parser actually do?
- It parses dot-notated Eloquent relationship strings such as posts.comments.author into structured arrays. You can then use those arrays to validate and eager load only the relations a frontend actually requested, without changing your API contract. It is a narrow, single-purpose utility that introspects your models' relation definitions rather than a query builder.
- How do I install laravel-relation-parser in a Laravel app?
- Install it with Composer using composer require salamwaddah/laravel-relation-parser. The package is a plain library: the v1.4.0 release implies no service provider registration and no config file to publish. Before merging, confirm the illuminate and php constraints in its composer.json actually admit the Laravel and PHP versions you run.
- Does it support nested relations like posts.comments.author?
- Yes. The package is built around dot-notation and resolves nested relationship paths into structured arrays. That lets you accept a single include query parameter from the frontend and expand it into something you can hand to with() or load(). Deep nesting is exactly the case where you should test the output shape against your own models.
- How do I validate that a requested relation exists before eager loading it?
- Resolve the requested include string through the parser, then use the resulting structure as a whitelist before calling with() or load(). Because the package derives its answer from your model declarations, it only knows about relations it can see in source. Anything it cannot resolve should be rejected at the boundary rather than passed straight into Eloquent.
- Which Laravel versions does it support, and is Laravel 13 supported?
- Version 1.4.0 is a compatibility release that adds Laravel 13 support; it ships no new features or API changes. What the changelog does not tell you is whether older Laravel or PHP versions were dropped in the same bump, since widening and narrowing constraints look identical in a release note. Diff composer.json between v1.3.0 and v1.4.0 and check the CI matrix before pinning it for production.
- Does the parser work with relations defined in traits or abstract base models?
- Relations declared indirectly, including via traits, abstract parent models, conditional registration, custom relation classes, or non-standard morphMap setups, are the most likely failure surface for any reflection-based parser. Test each of those patterns against your own codebase rather than assuming they resolve. Pay attention to whether it fails loudly or returns a plausible but incorrect relation, because silent misparse is far worse than an exception.
- Should I require it as a dev dependency or a production dependency?
- The recommended default is require-dev, since the package is typically consumed by tooling such as schema or ERD generation, API resource scaffolding, permission graph builders, and audit jobs. That keeps zero runtime footprint in your request-handling code. Promote it to require only if a genuine production path, like an admin schema browser or a generated-API layer, needs live introspection.
- What are the alternatives to using this package for include parameters?
- You can validate include strings yourself against a hard-coded map of allowed relations, or use a broader query-parameter package such as spatie/laravel-query-builder. Eloquent's own with() and load() already accept arrays, so the parser's value is purely in turning dotted strings into safe, validated structures. If your include set is small and static, hand-written validation is often the cheaper option.
- Is laravel-relation-parser actively maintained?
- It is a single-maintainer project with a low bus factor, and release cadence is driven by that one contributor. The v1.4.0 PR also comes from the maintainer, which shows responsiveness but does not change the bus factor. It is still pre-2.0, so wrap it behind an internal adapter so call sites do not depend on its return types directly.
- How should I pin the version in composer.json?
- Pin minors explicitly, for example 1.4.*, rather than floating, and let the lockfile be the contract. Pin ^1.3 if you are on an older Laravel and v1.4.0 turns out to narrow constraints; move to ^1.4 only once you have confirmed the constraint diff and that Laravel 13 is either GA or irrelevant to you. There is no published backward-compatibility policy for 1.x, so treat every minor as potentially return-shape-affecting.