Recently Laravel Package

Technical Evaluation

Architecture fit. awcodes/recently is an additive Filament panel plugin, not a framework-level dependency. It integrates through three supported extension points only: the panel plugin registry (->plugins([RecentlyPlugin::make()])), a page-level trait (HasRecentHistoryRecorder on EditRecord/ViewRecord), and a render hook (PanelsRenderHook::USER_MENU_BEFORE by default, overridable via renderUsingHook()). It also contributes a RecentEntryResource that participates in Filament's global search. No core patching, no service-provider overrides, no middleware. This is the lowest-friction integration shape Filament offers, which is the main argument in its favor.

Integration feasibility. Straightforward for a team already on Filament 4.x/5.x: composer require awcodes/recently, php artisan recently:install, register the plugin, add the trait to two page classes, done. Two non-obvious prerequisites carry most of the real effort: (1) a custom Filament theme must exist and the package's Blade views must be added to the theme CSS via @source '../../../../vendor/awcodes/recently/resources/**/*.blade.php' — meaning a front-end asset build step and rebuild are mandatory, not optional; (2) the package ships at least two migrations (base table, plus the v3.2.0 track_records migration published under the recently-migrations tag), so schema change control must be sequenced.

Technical risk.

• Version-mapping ambiguity. The README compatibility table states 2.x → Filament 5.x, while the v2.0.0 release note says "Support for Filament v4" and v3.0.0 says "Filament v5 support," with v3.1.0 collapsing v4 and v5 onto one line. A TPM must treat the matrix as unreliable and pin by verifying composer.json constraints in the tag, not the README.
• Single-maintainer, thin-adoption profile. 43 stars, 0 dependents, MIT, one primary author (well-known in the Filament ecosystem, which mitigates but does not remove bus factor). Zero dependents is expected for a leaf UI plugin but means no third-party validation of behavior at scale.
• Data-surface expansion. The plugin introduces a persistent table keyed to users and polymorphic records, plus an admin-visible resource. That is new PII-adjacent surface (record titles/URLs surfaced to users) and a new authorization question the docs do not answer.
• Write amplification. Tracking fires on every EditRecord/ViewRecord page hit, which is a per-pageview write on your primary database.

Key questions.

1. Does the plugin scope entries by Filament tenancy? With multi-tenant panels, can a user see "recently viewed" titles for records belonging to a tenant they have since lost access to?
2. Does it re-check policy on render, or only at record time? The 1.0.4 "add auth check to query scope" note suggests scope-level filtering exists, but the semantics for post-hoc permission changes are undocumented.
3. What exactly is persisted — record title, URL, morph class + ID? If a resource class is renamed or a panel path changes, do entries rot?
4. What is the expected row volume per user per month, and is max_stored_items/prune_after_days sufficient without an index review?
5. Is the contributed RecentEntryResource exposed in panel navigation and global search by default, and can it be hidden without forking?

Integration Approach

Stack fit. Laravel (up to Laravel 13 per v3.0.2) + Filament panels 4.x/5.x, PHP 8.2+. The package is strictly useless outside Filament panels — if any part of the admin surface is Livewire/TALL but not Filament, it will not cover it. Use the 3.x line: it supports Filament 4 and 5 on one release line, which removes a major-version fork from your upgrade path.

Migration path. Pin ^3.1 initially (v4/v5 dual support, no forced migration), then move to ^3.2 when you want pruning and deleted-record hiding. v3.2.0 is explicitly backward-compatible: "Every new option defaults to the current behavior." The only upgrade friction is the track_records migration, which is opt-in but must be published and run before enabling the flag.

Compatibility. Two documented conflicts: OverlookPlugin and QuickCreatePlugin both need RecentEntryResource::class added to their excludes([...]), otherwise the plugin's own bookkeeping resource shows up in their pickers. Also verify SPA mode (fixed in 1.0.4) and any custom theme pipeline — a missed @source line yields an unstyled dropdown, not an error, so it fails silently in review.

Sequencing.

1. Confirm Filament major against the tag's actual composer.json, not the README table.
2. Install on a staging panel with menu(false) and globalSearch(false) — no UI exposure yet.
3. Add the theme @source directive, rebuild assets, verify the dropdown renders styled.
4. Instrument two or three high-traffic resources with the trait; measure row growth and query cost for two weeks.
5. Enable the menu, then global search. Global search is the higher-noise, higher-visibility change; ship it second.
6. Enable max_stored_items and prune_after_days, and confirm model:prune is actually scheduled.
7. Enable track_records (with its migration) and decide deliberately on include_trashed_records.

Operational Impact

Maintenance. ~One table, one resource, one trait, one render hook, one config file. The code surface you own is small; the surface you inherit is a dependency on a solo maintainer plus a theme build step that must survive every Filament upgrade. Release cadence is healthy (Dependabot bumps, CI, a recent feature release responding to community proposals in #39/#40), which is a positive signal for responsiveness despite the low star count.

Support. No commercial backing. GitHub issues, a docs site (docs.aw.codes/recently), and Filament community channels. Escalation path for a production incident is effectively "read the source" — budget accordingly.

Scaling. The dominant cost is one write per tracked page view. At meaningful admin traffic this is the first thing to break: it competes with business writes on the primary, and the table grows monotonically until pruning is enabled. Levers: max_items (UI only) vs. max_stored_items (storage) vs. prune_after_days (scheduler-driven) are three distinct knobs — teams routinely set only the first and are surprised later. Confirm an index on the user key before enabling broadly.

Failure modes.

• Migration not published/run → runtime query errors on panel load.
• Theme @source omitted → silently unstyled menu.
• model:prune unscheduled → unbounded table growth.
• Trait added to a page without the resource registered for the panel → entries recorded but unresolved.
• Deleted records → dead links in the menu and global search (fixed only if track_records is enabled; soft-deletes need include_trashed_records).
• OverlookPlugin/QuickCreatePlugin unexcluded → internal resource leaks into user-facing pickers.
• Multi-tenant permission drift → stale entries shown for records the user can no longer access.
• Render hook collision at USER_MENU_BEFORE if other plugins target the same slot.

Ramp-up. Low for anyone fluent in Filament plugin conventions: roughly half a day to install, theme, and validate in staging. The real cost is the review window — half a day to a day of engineering plus a security/privacy pass on tenancy and policy evaluation before this goes panel-wide. Total credible estimate: one engineer, two to three days, gated on the tenancy answer.