Getting Started

Install the package with Composer, then publish its config and assets (php artisan vendor:publish --tag=...). Check the package README for the exact provider/tag names before running anything else.
Release 1.4.2 requires a build step before the package is usable. Run npm install && npm run build in the package (or host app, depending on how assets are wired) so the compiled frontend is present. Do not skip this — the package will load stale or missing assets otherwise.
Update the search index before first use. Look for an artisan command exposed by the package (e.g. php artisan <package>:index or a Scout-style scout:import). If no command is documented, check the package’s service provider for registered commands.
First use case: wire the package into a single Blade view or route, build assets, refresh the index, and confirm search results appear. This validates the full install path before rolling it out.

Implementation Patterns

Post-install / post-update workflow: after every composer update that touches this package, run npm run build and refresh the search index. Treat these as part of the deploy, not optional local steps.
CI/CD: add a build step (npm ci && npm run build) and an index refresh step to your pipeline. If the index is large, run the refresh as a queued job or scheduled command rather than blocking deploy.
Local development: if the package serves compiled assets, keep npm run build in your setup script (e.g. composer post-autoload-dump or a project make setup target). Document it in the onboarding notes so new developers don’t hit blank UI or empty search.
Scheduled index refresh: if the package searches application data, schedule the index update (e.g. every N minutes, or on model events) so results stay current between deploys.
Integration: bind the package’s search service or component where needed, and publish only the config keys you actually override. Keep overrides in config/ rather than editing vendor files so future releases remain upgradeable.

Release 1.4.2 is a build-sensitive release. The note “npm run build and update search index before running” means a plain composer update is not enough. Skipping the build leaves old assets; skipping the index update leaves empty or stale results. Both failures look like bugs but are setup issues.
Debugging empty search: first confirm the index was rebuilt after the update, then clear Laravel caches (php artisan cache:clear, config:clear, view:clear). Only after that investigate package code.
Asset publishing quirks: if assets are published to public/vendor/..., re-publish after upgrading, or point the package at its own build output. Check whether the package expects assets in the host app’s public/build or its own directory.
Version pinning: pin the package version in composer.json if you cannot guarantee the build/index steps in every environment; otherwise a minor release can silently require a rebuild.
Extension points: use the package’s published config and events/observers for index updates rather than forking. If the package exposes a search driver or indexer contract, bind your own implementation instead of modifying vendor code.