Laravel Shareable Models Laravel Package

Product Decisions This Supports

• Shipping "share" as a feature, not a project. The package turns any Eloquent model into a guest-accessible link (invoice, report, ticket, draft doc) without standing up an external-viewer auth or permissions model. That is usually the difference between a two-day task and a quarter-long portal epic.
• Build vs. adopt. It replaces roughly 1–2 days of schema, token generation, routing, and middleware work with a trait plus a migration. Correct call when sharing is a supporting capability rather than the product itself.
• Public identifier policy. It decouples public URLs from primary keys, forcing an explicit decision — opaque, revocable tokens versus /invoices/1234 — instead of letting each feature improvise. Worth standardizing on early.
• Access lifecycle decisions. Revocation (delete the link), expiry, and optionally a password gate map directly to the support and compliance asks we actually get: "make this stop working," "make this expire Friday," "don't let it be guessed."
• Roadmap sequencing. Lets a sharing capability land in a minor release ahead of any permissions or customer-portal work, buying time to learn whether customers use it.
• Explicitly not supported: per-recipient permissions, multi-tenant scoping, audit trails, view analytics, watermarking, or compliance-grade access evidence. If those appear on the roadmap, this is a prototype, not the destination.

When to Consider This Package

Consider it when:

• You're on a Laravel version this actually supports. The last release is March 2023, so treat Laravel 10+ compatibility as an open question and verify before committing.
• The unit of sharing is a single Eloquent model, read-only, one link per grant.
• You need revocation or expiry — precisely what Laravel's native signed URLs don't give you without extra bookkeeping.
• The security bar is "unguessable and revocable," not "audited, scoped, and rate-limited."
• You're comfortable owning the code. 268 stars, 0 dependents, and a three-year-old release mean that in practice you are the maintainer; the MIT license makes vendoring and forking straightforward.

Look elsewhere when:

• Requirements include recipient identity, granular permissions, download controls, or view analytics.
• Upstream maintenance and framework currency are hard requirements rather than nice-to-haves.
• Sharing is core to the product (customer portals, external collaboration) — own the schema and build it deliberately.
• You only need time-boxed access with no revocation need; Laravel signed URLs solve that with zero dependencies and zero maintenance surface.
• The zero-dependents signal matters to your risk process — it's weak evidence of quality either way, but it means no ecosystem pressure to keep it current.

How to Pitch It (Stakeholders)

Executives: A small, free (MIT), single-purpose library that lets us add "share this with someone outside the app" in days rather than a quarter. It generates unguessable, revocable links to individual records — no external accounts, no new permissions model, no new vendor relationship. Cost is near zero and the blast radius is small. The real risk is maintenance: last release was 2023, so we should treat it as code we own. Recommendation: adopt it behind a thin internal abstraction so we can fork or replace it without touching product code.

Engineering: One trait on the model, one polymorphic table, tokens instead of IDs. Wrap it in our own ShareLinkService so the package stays an implementation detail; add rate limiting, logging, and any access analytics at our layer, because the package won't provide them. Budget half a day for integration plus a compatibility check against our Laravel version, and assume we may need to fork for future framework upgrades. Exit cost is low by design — that's the main reason to say yes.