Revive Laravel Package

Technical Evaluation

Architecture fit

• Revive is a Filament panel plugin, not a general Laravel package. Its value is entirely contingent on already running Filament v5 (or v4/v3 via pinned majors) as the admin surface. In a non-Filament app it is close to useless; the only reusable piece is the Recyclable trait and the tracking/discovery layer, and the Livewire table is still Filament-shaped.
• The design is sound for the problem: a Recyclable trait, a plugin registration per panel, and a dedicated page. It layers on top of Laravel's SoftDeletes rather than replacing it, so withTrashed()/onlyTrashed() semantics and existing restore paths remain intact.
• Introducing a second "source of truth" for deleted records (the plugin's tracking table plus state snapshots) is the key architectural question. It duplicates data already in the model table and creates a sync obligation (revive:discover-soft-deleted exists precisely because the tracking table can drift from reality).

Integration feasibility

• Low ceremony: composer require, revive:install, register RevivePlugin::make() in the panel, add the trait to target models. Config is fluent and discoverable (authorize, navigationGroup, models, scoping flags).
• Scoping is the strongest feature for our context: user scoping, tenant scoping, showAllRecords(), and an authorize() closure give us distinct user/admin/tenant panels without forking.
• Namespace resolution via Composer PSR-4 is convenient for DDD/modular layouts, but it is implicit magic — a misconfigured namespace is "skipped and logged," i.e., silently empty recycle bin. Third-party models require wrapper classes, which is an adoption tax.
• Embedding @livewire(\Promethys\Revive\Tables\RecycleBin::class) outside a panel is a viable escape hatch for one-off screens.

Technical risk

• Adoption risk is the headline. 16 stars, 0 dependents, no ecosystem validation. We would be among the first production users, and effectively the QA function.
• Bus factor of one. No indication of a maintainer team or funding. MIT means we can fork, but forking a Filament-coupled package means inheriting its upgrade treadmill.
• Filament major-version churn. The README itself enshrines a three-track release strategy (V1 critical-fixes-only / V2 maintenance / V3 active). This is a maintainer signalling that only the newest track gets real attention. Every Filament major forces a Revive major, and with one maintainer the lag between Filament release and Revive compatibility is unbounded.
• Data exposure. State snapshots persist model attributes at deletion time into a separate table. That is a second copy of potentially sensitive fields, outside whatever retention/erasure policies we apply to the primary table. This needs explicit review before it touches PII.
• Restore correctness. Restoring a soft-deleted row can violate unique constraints, foreign keys, or state invariants that changed since deletion. The plugin restores rows; it does not (and cannot) guarantee business-level restorability. Permanent delete likewise may bypass model events/observers we rely on.
• Migration hygiene. The README documents a real failure mode where re-running revive:install republishes migrations with fresh timestamps on spatie/laravel-package-tools < 1.93.1. That is a dependency-floor footgun for teams that pin older versions.

Key questions

1. Is our admin surface already Filament v5, or are we several majors behind? If the latter, we are adopting a package that only actively supports a version we don't run.
2. Do we actually need the tracking table and snapshots, or is a straightforward onlyTrashed() Filament resource sufficient? Building that in-house is days, not weeks, and removes the dependency entirely.
3. What is our GDPR/data-retention posture on duplicate attribute snapshots, and can we disable or scope them?
4. Which models are genuinely restorable — i.e., have we verified that restoring a row at day 30 doesn't violate uniqueness or referential integrity?
5. Who owns the fork if the maintainer disappears, and what is our tolerated lag behind a Filament major upgrade?

Integration Approach

Stack fit

• Requires PHP 8.2+, Laravel 11+, Filament v5 for V3. This aligns with a modern Laravel baseline but forces our hand on Filament version — we cannot adopt Revive and defer a Filament upgrade.
• Fits cleanly into existing panel providers; no service-provider surgery, no custom middleware, no route conflicts. Multi-tenancy integration piggybacks on filament()->getTenant(), so it inherits our tenancy model rather than inventing one.

Migration path

• Pin the major explicitly (^3.0 for Filament v5) rather than floating. The three-track release strategy makes an unpinned constraint a latent upgrade hazard.
• Run revive:install once, verify migration idempotency against our spatie/laravel-package-tools version, and commit the published migration so future install runs cannot re-timestamp it.
• For existing soft-deleted data, run revive:discover-soft-deleted --dry-run first in staging, then --with-scope, targeting the correct --panel (defaults to the default panel, which may not be the one configured with modelsNamespace()).
• Upgrading later from V2 → V3 is schema-neutral per the README, which is a good sign for forward migration cost; V1 → V2 is not, and requires new migrations.

Compatibility

• Hard requirement: SoftDeletes must be present alongside Recyclable or the trait throws. Enforce this at CI (a small test that iterates registered recyclable models) rather than discovering it at runtime.
• Third-party models need wrapper subclasses in a scanned namespace; budget for these wrappers as part of the integration, not as a later cleanup.
• Namespace configuration replaces the default App\Models rather than augmenting it — an easy mistake that silently empties the bin.

Sequencing

1. Spike: stand up Revive in a staging panel against one low-risk model (e.g., Comment) to validate install, scoping, and restore behavior end to end.
2. Data review: decide on snapshot retention, PII fields, and whether to disable snapshots.
3. Roll out trait adoption model-by-model, ordered by business criticality, with a restore-integrity check per model.
4. Configure distinct panels last (user-scoped, tenant-scoped, admin showAllRecords() with authorize()), since panel config is where misconfiguration causes data leakage.
5. Run discovery against existing production soft-deletes only after scoping config is verified in staging.

Operational Impact

Maintenance

• We inherit an upgrade obligation tied to Filament majors, on a package with one maintainer and a documented "critical bug fixes only" track for older versions. Realistically, we should plan to vendor or fork the package at first adoption friction.
• The tracking table introduces ongoing reconciliation work: records soft-deleted outside the app (raw SQL, jobs, other services) will not appear in the bin until discovery runs. That is a recurring operational task, not a one-time migration.
• Snapshot storage grows unboundedly unless we define retention. This will need a pruning job we own.

Support

• No commercial support, no docs site beyond the README, no dependents to consult. Internal ownership must be explicit: one named engineer who can read the Filament internals the plugin touches.
• Community support is effectively the issue tracker of a 16-star repo. Response times should be assumed to be "best effort, indefinite."

Scaling

• The recycle bin page lists deleted records across all registered models. On high-volume tables (orders, events, logs) this becomes a slow, wide query with filters over a union of model types. We should restrict ->models([...]) to genuinely recoverable entities and exclude high-churn tables.
• State snapshots scale linearly with deletion volume, which for high-churn models is significant. Size this before enabling broadly.
• Multi-tenancy scoping helps query selectivity; showAllRecords() on an admin panel will not, and should be paginated/guarded.

Failure modes

• Silent empty bin from an unresolvable modelsNamespace() — logged, never fatal. Needs an alert or a smoke test.
• Duplicate migrations from re-running revive:install on older laravel-package-tools.
• Restore failures on unique/FK violation surface as exceptions in a Livewire action; the UX for these is unverified and likely raw.
• Cross-tenant leakage if showAllRecords() is configured on a tenant panel or authorize() is a static true.
• Snapshot PII leakage into a table outside our erasure pipeline.
• Filament upgrade breakage with no fixed timeline for a compatible Revive release.

Ramp-up

• Developer ramp-up is genuinely low — hours, not days. The README covers install, trait, scoping, and panel config with copy-pasteable examples.
• Operational ramp-up is moderate: someone must own reconciliation, retention, and restore-integrity verification.
• The honest TPM read: this is a commodity feature (a onlyTrashed() Filament resource plus restore/force-delete actions) available from a very thin dependency. Adopt it to save a few days, but treat it as a fork candidate from day one and keep the in-house alternative costed — at 16 stars and 0 dependents, the build-vs-buy line is closer than the convenience suggests.