Laravel Scout Bulk Actions Laravel Package

Product Decisions This Supports

• Deploy and release runbooks for search. If the product depends on search relevance, reindexing is a release-blocking operational step, not an engineering chore. This package collapses a per-model checklist into a single command, which lets a PM treat "reindex all searchable models" as one documented, repeatable gate that a release engineer can run rather than a script only the original author understands. Fewer manual steps in a runbook means fewer "we forgot to reindex Posts" incidents.
• Index rebuilds as a user-facing availability decision. The --fresh flag and scout:refresh behave differently, and that difference is a product tradeoff, not a technical detail. scout:refresh empties every index before importing, so search is degraded or empty for the whole rebuild; --fresh removes one model at a time for only its own import window. That is the difference between "search is broken for two hours during a migration" and "search stays up, one content type gets momentarily thin." A PM should be the one deciding which is acceptable per release.
• Perceived freshness during long rebuilds. --order=desc on scout:queue-import-all indexes the newest rows first, so on a multi-hour rebuild recent content returns to search early instead of last. This directly affects what users see in the first hours after a large import — relevant for launches, backfills, and content migrations where recency drives the experience.
• Scoping search work in the roadmap. The package's model-discovery config (directory scanning, glob patterns for Modules/*/Models) is a proxy for how much searchable surface the product has. If the config needs more than a couple of paths, that's a signal the search feature has grown into a multi-domain concern needing its own owner, not a side task.
• Build vs. buy, honestly. The underlying capability is thin: walk directories, reflect on classes, check for the Searchable trait, loop a native Scout command with a progress bar. That is a strong argument for adopting rather than building, and an equally strong argument that the ceiling on differentiation here is low. Adopt it to reclaim engineering hours; do not put it on a roadmap slide.
• CI and change-control hygiene. Production confirmation prompts plus --force for automated pipelines mean reindexing can be wired into CI/CD with an auditable, single entry point. Good for teams that need evidence that index state is reproducible across staging and production.
• Onboarding and bus factor. Discoverability is automatic, so a new engineer can rebuild search without knowing which ten models implement Searchable. That reduces the "only one person can do this" risk on a critical workflow.

When to Consider This Package

Adopt when most of these hold:

• Three or more searchable models, or a modular codebase where models live outside app/Models. Below that threshold, native scout:import per model is fine and adding a dependency is not worth it.
• Reindexing happens regularly — on deploys, after schema changes, during content migrations, or as part of environment seeding — rather than once at launch.
• Dataset is large enough that synchronous indexing blocks a pipeline, making scout:queue-import-all and chunk/queue targeting genuinely useful.
• Search availability during rebuild is a user-visible concern, so the --fresh vs scout:refresh distinction matters and someone will actually choose between them.
• The team tolerates a small, single-maintainer dependency for operational convenience, and is comfortable pinning a version and forking if needed.

Look elsewhere, or write the twenty lines yourself, when any of these hold:

• Only one or two searchable models. Marginal value.
• You need partial-failure resilience. The README is explicit: if any single model fails, the command stops immediately with a failure exit code. There is no per-model retry, no skip-and-continue, no resumability. On a long queued rebuild across many models, one bad model means starting over. For a large production index this is a real operational risk and a reason to build a wrapper with per-model isolation.
• You need observability. No metrics, no structured reporting, no per-model timing or record counts beyond a progress bar, no dry-run. If you want to answer "how long did the Post index take and how many rows landed," this does not tell you.
• You need index configuration management. This moves documents only. It does not manage Meilisearch/Typesense/Algolia index settings, filterable attributes, ranking rules, or synonyms. That is a separate problem and often the harder half of search work.
• Multi-tenancy or permission-scoped indexes are in play. Auto-discovery over all models is the wrong default when indexing must be partitioned per tenant or per access level.
• Dependency risk is unacceptable. Fourteen stars, zero dependents, one maintainer. The code surface is small and MIT-licensed, so the fallback is genuinely cheap — but treat it as "vendorable snippet" rather than "trusted infrastructure."
• You already have an internal artisan command or deployment task that does this and more; do not add a parallel path.

How to Pitch It (Stakeholders)

For engineering: A drop-in that replaces N per-model scout:import calls with one auto-discovered, progress-tracked command, plus queued bulk imports with chunk and queue targeting, ordering control for long rebuilds, and production confirmation gates with a --force escape hatch for CI. Requires PHP 8.2+ and a recent Laravel Scout; supports Laravel 13 and Scout 11. Small, MIT, actively maintained, small enough to fork if it stalls. Honest caveats to state up front: it halts on the first model failure with no retry or resume, and it does not touch index settings — so if we put it in a production rebuild path, we should wrap it with per-model isolation and logging.

For executives: This is plumbing, not a feature. It removes manual, error-prone reindexing steps from our deploy process — the kind of work that costs engineering hours and occasionally causes "search is empty" incidents after a release. It is free, MIT-licensed, and adoptable in an afternoon. Two things to be clear about: it does not increase engineering headcount or capacity in any meaningful way, and it is maintained by one person, so we treat it as a convenience layer with a cheap fallback rather than a dependency we build strategy on. If we ship multi-model search on a regular release cadence, adopt it and write the runbook; if we have two searchable models and reindex twice a year, skip it.