Recently Laravel Package

Technical Evaluation

Architecture fit. awcodes/recently is a thin, opinionated Filament panel plugin rather than a general-purpose Laravel package. It has four moving parts: a persisted recent_entries table (published migration), a RecentEntryResource that surfaces tracked entries, a Blade dropdown injected via the PanelsRenderHook::USER_MENU_BEFORE render hook (configurable to other hooks), and an opt-in HasRecentHistoryRecorder trait added to individual EditRecord / ViewRecord pages. Configuration is split between config/recently.php (user_model, max_items, width, global_search, menu, icon) and fluent per-panel overrides (globalSearch(), menu(), icon(), rounded(), label(), width(), maxItems(), renderUsingHook()). This is a good architectural fit only if we are already standardized on Filament panels; there is no standalone (non-Filament) path, and the package assumes it can own the user menu region of the topbar.

Integration feasibility. Install is a two-step composer + php artisan recently:install wizard, followed by one line in the panel provider and a trait on selected pages. The real integration cost is not PHP — it is frontend: the docs explicitly require a custom Filament theme and an @source '../../../../vendor/awcodes/recently/resources/**/*.blade.php' addition to the theme CSS. Teams that have not yet built a custom theme (common in early-stage internal panels) inherit that entire Tailwind/Vite theme pipeline as a prerequisite. Two known plugin conflicts (QuickCreatePlugin, OverlookPlugin) require explicitly excluding RecentEntryResource, which implies the package leaks a resource into shared plugin surfaces and needs coordination when those plugins are added later.

Technical risk. Low-to-moderate, and mostly ecosystem risk rather than code risk:

• Version coupling is the primary risk. Major versions track Filament majors (1.x → Filament 3, 2.x → Filament 4 per release notes, 3.x → Filament 4 & 5). The README compatibility table lists 2.x as Filament 5.x while the v2.0.0 release note says "Support for Filament v4" — a documentation inconsistency that must be resolved against actual composer.json constraints before we pin anything.
• Data lifecycle was unbounded until recently. Pruning (max_stored_items, prune_after_days via model:prune) and dead-link suppression (track_records, include_trashed_records) only arrived in v3.2.0 and are opt-in. Older pins grow the table indefinitely and surface "not found" pages for deleted records.
• Authorization surface is the highest-severity unknown. Entries render record titles and link directly to edit/view pages; if entries are not filtered through Filament resource authorization (policy view/viewAny/tenant scoping), users can see breadcrumbs to records they can no longer access. A v1.0.4 fix ("add auth check to query scope") suggests user scoping exists, but resource-level policy enforcement is not documented.
• Adoption signal is weak. 43 stars, 0 dependents, README + releases only (no visible test matrix or coverage claims). The maintainer is a known Filament-ecosystem author, which offsets bus-factor concerns more than production-validation concerns.

Key questions for the maintainer / spike.

1. Are entries filtered by the target resource's canView() / canAccess() and by the current panel's tenancy, or only by user_model + panel ID?
2. Is the write path synchronous on page render, or deferred — and does it dedupe repeat visits to the same record?
3. Does the topbar render hook execute a query on every panel page load? Is there caching, a limit clause, or lazy loading (Livewire) around the dropdown?
4. What indexes exist on recent_entries (user_id, created_at, panel/tenant columns), and what is the retention default with pruning disabled?
5. Are entries namespaced per panel, so a record visited in an admin panel doesn't appear in a customer-facing panel?
6. Does the global-search integration add query cost per keystroke and can it be scoped to resource types?
7. Is tracking failure-tolerant (does a DB exception on write break the edit page render)?

Integration Approach

Stack fit. Appropriate only for Laravel applications running Filament panels (v4/v5 on the 3.x line, v3 on 1.x) with a custom theme already in place or planned. It is a UX affordance for internal/admin tooling — a navigation accelerator, not a data or workflow primitive. Nothing else in the stack should depend on it.

Migration path and sequencing.

1. Pin verification (blocking): resolve the actual Filament constraint for the 3.x line from composer.json and confirm it against our pinned Filament minor. Do not trust the README matrix alone.
2. Spike in one non-production panel: install, run recently:install, add the theme @source directive, register RecentlyPlugin::make(), and enable the trait on exactly one high-traffic resource's EditRecord. Validate menu rendering, dark mode, SPA mode, and panel path prefixes.
3. Authorization audit before wider rollout: create a low-privilege user, view a record, revoke access, and confirm the entry is either hidden or blocked on click. This is the go/no-go gate.
4. Incremental trait rollout by resource, ordered by edit frequency. Trait placement is per-page, so coverage is a deliberate decision, not an automatic one — expect to maintain a checklist and re-check it whenever new resources ship.
5. Enable the v3.2.0 data-hygiene options — publish and run the track_records migration, set max_stored_items and prune_after_days, and schedule php artisan model:prune. Do this before traffic, not after.
6. Decide menu and global-search posture explicitly. Global search defaults to on and will interleave recent records into search results; default it off per panel unless product explicitly wants it, and revisit.
7. Conflict registration: add RecentEntryResource::class to OverlookPlugin / QuickCreatePlugin excludes as part of the same change set, so later plugin adopters don't rediscover it.

Compatibility and upgrade cadence. Because package majors are welded to Filament majors, our Filament upgrade playbook must include this package as a first-class line item: Filament major bump → package major bump → re-publish config/migrations → re-verify trait placement and render hook. Budget this as recurring, low-effort-but-mandatory work. Laravel 13 support landed in the 3.0.2 line, so the package is reasonably current on framework dependencies; no concern there.

Operational Impact

Maintenance. Low code surface, MIT, actively released (dependabot automation and multi-version CI visible in release notes). Single-maintainer project with no downstream dependents — treat it as a convenience dependency with a documented exit path (drop the plugin, keep or delete the table, remove the trait). The exit cost is genuinely small, which is the strongest argument for adoption.

Support. GitHub issues only, no SLA, documentation at docs.aw.codes plus in-repo README. Community translations are partial (German, pt_BR contributed). Internal teams should expect to read the source for anything not covered by the README — plan for one engineer to own familiarity with it rather than assuming self-service.

Scaling considerations.

• Read amplification: the topbar dropdown via USER_MENU_BEFORE is a per-page-load concern. If it queries synchronously, every Filament page view pays an indexed lookup. At internal-admin traffic levels this is negligible; in a high-seat-count panel it should be verified and, if needed, cached or lazy-loaded.
• Write amplification: one row per tracked edit/view. Fine for tens of users, needs pruning discipline (or an async write) at hundreds.
• Storage growth: bounded only if max_stored_items / prune_after_days are configured. Make pruning part of the install runbook rather than an optional hardening step.
• Global search: adds a query per search invocation and dilutes result relevance. Default off, opt in per panel where it demonstrably helps.

Failure modes and mitigations.

Ramp-up. Developer ramp-up is genuinely low — one plugin registration line and one trait per page, well documented. The real ramp-up is operational: theme build pipeline ownership, migration sequencing across environments, scheduled pruning, and a standing checklist for new resources and plugin conflicts. Call it half a day for the first panel including the theme work, and near-zero marginal cost afterward.

Recommendation. Adopt with guardrails for Filament-based internal admin panels, contingent on the authorization audit passing and the Filament constraint being confirmed from source. Do not adopt as a platform-wide dependency, do not expose it on tenant-scoped or customer-facing panels without verified scoping, and do not treat it as a source of truth for user activity analytics — it is a navigation convenience, and pruning means it is deliberately lossy.