Scoutify Laravel Package

Technical Evaluation

Verdict: A well-scoped, thoughtfully built UI package with an unusually complete feature surface for its maturity level — but it is pre-adoption software (1 star, 0 dependents, no production reference), and three of its design choices (boot-time model discovery, automated source-file rewriting, and a fail-open authorization default) are the kind of things a TPM should gate on before it touches a customer-facing surface. Recommend a time-boxed spike, not a roadmap commitment.

Architecture fit

• The package is a presentation-layer concern: a Livewire component plus a Searchable trait/GloballySearchable contract mixed into Eloquent models. It sits on top of an existing Laravel Scout index and does not own the search engine, the index schema, or the query DSL — that is the right seam. Swapping it out later is a trait removal and a Blade partial deletion, not a data migration.
• The coupling is inward (your models depend on a third-party contract) rather than outward. That is manageable but non-zero: each registered model gains an interface, a trait, and up to six optional globalSearch*() overrides. Ten models means ten files carrying a vendor dependency.
• The Livewire requirement is the real architectural gate. Apps that are Blade + Livewire already get near-zero friction. Inertia/React/Vue or API-first front ends would need a Livewire island hosted on a Blade route — technically possible, practically a product-shaped detour. Treat this as a hard "no" for SPA-first stacks.

Integration feasibility

• Install path is two commands, but scoutify:install is invasive by default: it prompts for a Scout driver, installs that driver's Composer packages, and publishes config/scout.php. On any app that already runs Scout, that publish step risks clobbering tuned config (searchable attributes, index settings, queue, chunk). This must be done on a branch with a config diff review, not on main.
• scoutify:searchable edits model source files — imports, implements, and trait insertion — with a --dry-run available. Auto-rewriting application source is the highest-friction item in the whole package from a change-management standpoint. Expect code-review pushback, and expect formatting edge cases (readonly classes, attributes, multi-class files, final declarations). Budget for hand-editing models instead; the interface is small enough that manual registration is a few lines per model and gives you cleaner diffs.
• The type manifest means there is a deployment step beyond composer install: the manifest must be rebuilt whenever a model is added or removed, and again on scoutify:import to populate the index. That has to be wired into your deploy pipeline, not left to a developer's laptop.

Technical risk

• Authorization is the top risk. The default secure mode allows any authenticated user to see a model's results when no policy or gate exists for that model. In a multi-tenant or role-partitioned application, a newly registered model therefore leaks by omission until someone writes a policy. The VisibilityRule builder is genuinely good — policy, Spatie permission, Spatie role, attribute, and closure rules, plus an AND/OR mode — but the safe posture is to mandate gate-only (fails closed) or implement HasGlobalSearchVisibility on every registered model. This is a config decision a TPM must own explicitly.
• Boot-time filesystem discovery of app/Models/ is a per-request cost and a deploy-environment hazard. It assumes models live in the canonical path (not app/Domain/*/Models, not a modular monolith), and it assumes a readable filesystem (fine for standard containers, questionable for read-only root or aggressively optimized OPcache setups). Confirm the manifest is cached to disk and that cache is part of the build artifact.
• Search quality expectations. Meilisearch uses word-boundary prefix matching, so "ano" will not find "Mariano" — the README says so plainly, which is honest, but end users will file it as a bug. The database driver (LIKE-based) is the low-risk pilot choice.
• Preview/download surface. Implementing HasGlobalSearchPreview adds a signed streaming route (scoutify.preview.stream) and, for non-temporary URLs, proxies file bytes through your application — direct bandwidth and worker-occupancy cost on S3/GCS disks whose temp URLs are unavailable. PDF/image/video rendering inline also means arbitrary user-uploaded content is rendered in an authenticated modal; treat that as a security review item, not a UI nicety.
• Maturity signals. One star, zero dependents, no security policy, single maintainer. The 2026-08-16 release date is anomalous relative to the rest of the metadata and should be verified against Packagist before you anchor a version constraint on it.

Key questions for the maintainer / spike

1. Is the model-type manifest cached to disk, and is it rebuilt automatically on deploy or only by an artisan command?
2. What happens to the modal when the Scout driver is unreachable or a query throws — does it degrade to an empty state, or surface a Livewire error?
3. Does scoutify:install overwrite an existing config/scout.php unconditionally, and is there a --no-publish flag?
4. What is the tested compatibility matrix for Scout 11 vs 12, and for the database driver specifically?
5. Is HasGlobalSearchVisibility fail-closed for guests under all three default modes? (README says permissive opens everything — confirm gate-only behavior with a missing gate.)

Integration Approach

Stack fit

• Target: Laravel 11/12/13, Livewire 3/4, Laravel Scout 11/12, Blade layout, Tailwind v4. Anything outside that box is unsupported and should be treated as a fork-and-patch decision.
• Tailwind v4 matters: the package inlines utility classes. If the host app is on Tailwind v3, or has an aggressive @source/purge configuration, expect missing or conflicting styles. The fluent theme API exists but is undocumented depth — verify it before promising visual consistency with a design system.
• Blade Icons is a soft dependency for anything beyond the default heroicon prefix. globalSearchIcon() accepting any registered pack prefix is a nice touch, but it means icon rendering correctness depends on Composer-installed packs being present at boot.

Migration path (adopt or revert)

• Adoption is additive: one Composer line, two config files, a Blade partial in the root layout, and trait + interface on selected models. No schema changes, no data migration.
• Reversion is mechanical: remove <livewire:scoutify::modal /> and the trigger, strip the trait/interface/overrides from models, drop the package and its published config. Estimate half a day for a handful of models. This is a genuinely low-regret trial — provided the auto-edit command is not run wholesale across the model directory.
• Constraint to flag early: <livewire:scoutify::modal /> must sit at the root of the layout, outside any collapsible container. Apps with off-canvas sidebars or drawer-based navigation that wrap the slot will find the modal silently fails to mount. This is a layout-refactor task, not a drop-in.

Compatibility checks before anything else

• Livewire version pinned and confirmed in composer.lock.
• Scout driver already operational, index populated, scout:import running cleanly.
• Tailwind version and build pipeline.
• Whether spatie/laravel-permission is present (only needed if you use ->permission() / ->role(); the package fails closed if used without it — good behavior, worth verifying).

Sequencing

1. Spike on a branch (1–2 days). Install with --no-publish-equivalent manual config merge, register one model by hand, database driver, fixed authorization to gate-only.
2. Authorization matrix. Enumerate every registered model × {guest, authenticated-no-policy, authenticated-with-policy, tenant-A vs tenant-B}. This is the gate; do not proceed without it signed off by the security owner.
3. Layout integration. Move the modal to root, verify keyboard trigger, focus management, and mobile trigger on real devices. Confirm WCAG AA claim in practice (focus trap, Esc, screen-reader announcements).
4. Pilot, 2–3 model types, staging soak (1–2 weeks). Watch query counts per search, Livewire request volume, and p95 modal open latency.
5. Expand or exit. Only promote beyond pilot once a cached manifest, a deploy-pipeline step, and a version pin are all in place.

Operational Impact

Maintenance

• Single maintainer, MIT, zero dependents. There is no organizational backstop and no evidence of a CVE/disclosure process. Plan on pinning to an exact version ("matheusmarnt/scoutify": "x.y.z"), vendoring or forking as a contingency, and treating upgrades as deliberate, tested events rather than composer update side effects.
• The auto-edit command is a recurring maintenance tax: every model added later needs registration, and the manifest rebuilt. Codify this in a checklist or a CI assertion that fails when a Searchable model exists without a registered type.
• Because models carry a vendor trait, a future Laravel or Scout major that changes the Searchable/Builder contract becomes your upgrade blocker, not just the package's.

Support

• Documentation is above average for a package this young: hosted docs site, changelog, releases, README with real caveats (the Meilisearch prefix note is the kind of honesty that usually correlates with a careful author). That partially offsets the maturity risk.
• Support channel is GitHub issues only. No SLA, no commercial backing. Budget internal ownership: one engineer should be the designated maintainer-of-record.

Scaling

• Search cost is per-model-type: one Scout query per registered type per search. Ten types means ten round trips (or ten parallel driver calls) per keystroke batch. Debounce is mandatory; consider capping the number of registered types.
• Livewire round trips per keystroke are the dominant latency factor at scale. Verify network payload and server response time under realistic type-ahead patterns, not a single happy-path search.
• Recent-search history writes to session on every search. Fine with Redis/memcached sessions; with file-based sessions on multi-node deployments it's a correctness and lock-contention problem. Confirm the session driver before enabling history.
• File preview/download is the sleeper scaling cost: server-proxied streaming consumes PHP workers for the duration of the transfer. Cap concurrency or restrict preview to temporary-URL-capable disks.

Failure modes to instrument

Ramp-up

• For a Blade/Livewire-comfortable engineer: under a day to a working modal on one model. The VisibilityRule fluent API is the only non-obvious surface — it's well-designed but needs a deliberate security walkthrough, not self-service discovery.
• For a team without Livewire exposure: add 2–3 days, and expect the "why is the modal inside the layout root" and "why is the trigger dispatching a browser event" concepts to be the sticking points.
• Overall: low technical adoption cost, moderate organizational cost (security sign-off, deploy step, version pin, single-maintainer contingency). The package is worth a spike on a Scout-enabled Blade app; it is not worth an architecture argument on an SPA-first stack.