Statamic Reverse Relationship Laravel Package

Product Decisions This Supports

• Content modeling & information architecture: the addon exposes the inverse side of a Statamic relationship (the "referenced by / appears in" view), which lets you decide whether a relation needs to be stored once and derived both ways, rather than duplicated as two mirrored fields that editorial must keep in sync.
• Build vs. buy: it is a narrow, single-purpose fieldtype addon. Adopting it is a cheap way to avoid funding a custom Laravel/Statamic fieldtype plus its ongoing upkeep, provided the maintenance risk below is acceptable.
• Editorial workflow roadmap: supports "where is this used?" navigation in the Control Panel without granting write access — useful for content audits, decommissioning assets/entries, and impact analysis before unpublishing.
• Release risk calls (v2.1.2): patch-level, no breaking changes, no new features, no deprecations. It is a safe in-place upgrade, and it removes two operational costs: (1) Composer-only installs now work without npm run build in CI, and (2) the field: null bug that could silently drop the configured relationship target when saving fieldtype settings.
• Follow-up action for the PM: any environment that saved reverse-relationship fieldtype config on ≤ v2.1.1 should have those field configurations re-verified after upgrading, since the bug wrote null rather than the selected field handle.

When to Consider This Package

Consider it when:

• You are on a supported Statamic version and already model content with Statamic relationship/entries fields — this addon complements, rather than replaces, that model.
• You want read-only reverse navigation for editors (no bidirectional sync, no auto-writeback of related entries).
• You deploy via Composer and prefer no Node/build step in the release pipeline — v2.1.2 is the first release that reliably ships working dist assets.
• You can tolerate a small, single-maintainer community addon and can pin the version; the upgrade cost between patches is low.

Look elsewhere when:

• You need true bidirectional relationships that write both sides automatically, or relationship data that must stay authoritative across systems (this is a display/navigation layer).
• Your requirements include complex relationship queries, reporting, or API output that depends on the reverse relation being a first-class, queryable field.
• You are pinned to an older Statamic major version — the v2.1.2 build fix targets the current @statamic/cms package layout, so the 2.x line should be validated against your exact Statamic version before adoption.
• Vendor-risk tolerance is low: no security review or long-term support commitment is implied by a patch release.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addon that lets editors see where a piece of content is used, without us building or maintaining custom code. The latest patch is a maintenance release — no new features, no breaking changes, and it removes a manual build step from our deployment process, which slightly reduces delivery risk and engineering time. The main consideration is that it is a community package, so we should pin the version and treat it as a replaceable convenience rather than core infrastructure.

For engineering: v2.1.2 fixes a Vue 2 event-binding bug (input vs update:value) that caused fieldtype configuration to save field: null, corrects the @statamic/cms dependency path in package.json, and rebuilds dist assets so the addon works from a plain Composer install. No API, schema, or migration surface changes. Recommend: upgrade, spot-check existing fieldtype configs for nulled relationship targets, and keep the Composer install path in CI as the primary distribution route rather than relying on a local build.