Meili Search Bundle Laravel Package

Technical Evaluation

Architecture fit — still poor, and 0.1.0 makes it worse, not better. The package remains a Symfony bundle: a Bundle subclass, a DI extension, a semantic config tree (meili_search:), compiler passes, service tagging/autoconfiguration. None of those concepts exist in Laravel. The new release notes confirm the trajectory rather than softening it — the stated roadmap item is Api-Platform support, and API Platform is itself a Symfony-ecosystem framework. The maintainer is investing in the PHP/Symfony API-framework axis, which is the axis furthest from a Laravel application. Nothing in 0.1.0 moves toward Laravel, PSR-only distribution, or framework-agnostic core.

Integration feasibility — low, unchanged. A Laravel port still requires a ServiceProvider, publishable config, a facade, and — for model integration — a Laravel\Scout\Engines\Engine implementation. Still zero dependents: no reference implementations, no community adapters, no one to ask. If anything, a fresh 0.1.0 is harder to port against than a frozen 2020 release, because the public surface is now explicitly pre-1.0 and moving. Rough estimate remains 3–6 dev-days to force-fit, producing a bespoke wrapper with no upstream. Compare to roughly 0.5 dev-day to configure Laravel Scout's first-party Meilisearch driver.

Technical risk — high, and the risk profile has changed shape. The 2020-era staleness concern is partly retired: there is a current release. But 0.1.0 is pre-1.0, which means no backward-compatibility commitment, no deprecation policy, and an API that the maintainer reserves the right to reshape as Api-Platform work lands. Two things stand out in the notes themselves:

• The version number is a red flag on its own terms. "Initial release" at 0.1.0, for a package that already had 0.x-style releases in 2020, implies either a version reset or a republish. Either way it tells us the project's history is not a reliable predictor of its API, and our dependency pin would be doing real work.
• The roadmap is a scope signal. "Api-Platform support in progress" means the next several releases will be spent on Symfony/API Platform integration — further away from Laravel, not closer.

The MeiliSearch server-drift risk from the previous assessment is now indeterminate rather than probably bad: we don't know which server generation 0.1.0 targets, and the release notes don't say. That is itself a finding — a release with no compatibility statement is a release you have to test against to characterize.

Key questions for the team:

• Is 0.1.0 a republish of the 2020 code under a new version, or a rewrite? The release notes say "initial release" and answer nothing. This determines whether the SDK-vs-server assumptions are 2020-era or current.
• Which MeiliSearch server version are we running or targeting? Still the decisive question, and the release notes don't address it.
• Does the maintainer intend any framework-agnostic path, or is the roadmap explicitly Symfony + API Platform only? Read the roadmap as written: it's the latter.
• What is the 0.x support policy — how many minor versions get fixes, and is there a 1.0 date? Absent an answer, treat every upgrade as potentially breaking.
• Do we need filtered/multi-tenant search (where clauses, tenant-scoped indexes), and is that expressible in Scout?
• Is this a spike or a production commitment? A spike has different risk tolerance — but a spike against a pre-1.0 Symfony bundle still costs more than a spike against Scout.
• What does the 4.69 opportunity score tell us? That the category — fast, typo-tolerant search — is attractive. It says nothing positive about this package, and a 0.1.0 release doesn't change that.

Integration Approach

Stack fit. Target: Laravel 10/11, PHP 8.2/8.3, meilisearch/meilisearch-php (official, actively maintained), laravel/scout (has shipped a first-party Meilisearch driver since Scout 9). Zero Symfony coupling anywhere in the graph. 0.1.0 does not alter this target — it simply re-confirms that the package lives on the other side of the line.

Migration path. Greenfield: no migration — adopt Scout and never add the bundle. If the bundle exists anywhere in our estate (still unlikely, still 0 dependents), extract its declarative index configuration — primary key, searchable/filterable/sortable attributes, ranking rules, synonyms, stop words — into config/scout.php plus searchableAs() and toSearchableArray() on models; rebuild with scout:import; dual-write during cutover; remove the bundle and its transitive Symfony constraints. If we were mid-evaluation, the 0.1.0 release is the natural point to stop rather than a reason to restart.

Compatibility matrix. Bundle 0.1.0: PHP 8.x / Symfony 6–7 components likely (unverified — the release notes state no requirements), MeiliSearch server version unspecified. Target: PHP 8.1–8.3, Laravel 10/11, MeiliSearch 1.x. The PHP overlap has probably improved; the framework overlap is still zero, and the MeiliSearch-server overlap is now unknown where it was previously assumed bad. Unknown is not better — it just moves the cost from "read the constraint" to "build a test harness."

Sequencing.

1. ADR recording the rejection of 0.1.0 specifically, noting that the new release does not change the framework-mismatch finding and that the roadmap points further into Symfony/API Platform (0.5 day) — this is the deliverable that prevents re-litigation when the next release lands.
2. Scout + MeiliSearch spike on one high-traffic model, including relevance comparison against current search (2 days).
3. Index design review — filterable attributes drive query cost and memory; get this wrong and scaling costs bite later (1 day).
4. Staging soak with a relevance baseline captured before/after (3 days).
5. Production rollout behind a feature flag with an instant fallback to the existing search path.
6. Confirm the bundle never enters the dependency tree; add a CI check if we're feeling thorough. Given the 0.1.0 republish, also watch for a rename/fork under a new package name that could slip past a name-based check.

Operational Impact

Maintenance. There is now a release signal, which is a genuine (if small) improvement over the previous five-year gap. It is not enough. Single maintainer, 11 stars, 0 dependents, pre-1.0 with no stated support policy, and a roadmap that spends its next increments on API Platform. Adopting still means owning a fork — a permanent, low-glamour tax on a team that has better things to do. Scout + the official SDK push that maintenance to vendors who actually do it.

Support. Unchanged. Single maintainer, 11 stars, 0 dependents: no Stack Overflow surface, no community answers, a thin issue history. On-call cannot escalate. When a MeiliSearch upgrade or a 0.x breaking change lands, we are the maintainers, whether we planned to be or not. The "initial release" framing means there is essentially no track record of responding to bug reports under this version line.

Scaling. The bundle contributes nothing here — it is configuration ergonomics, and 0.1.0 does not change that. Real scaling levers live in MeiliSearch itself: it is memory-resident, so index size maps to RAM; reads scale via infrastructure replication, not application code; write throughput is bounded by the task queue, so scout:import and queued indexing jobs need batching and backpressure. Budget for reindex duration as a recurring operational cost, not a one-off.

Failure modes.

• 0.x compatibility break: a 0.2.0 minor bumps a signature or renames a config key, and our wrapper breaks on a routine composer update. Pre-1.0 makes this the expected case, not the tail case.
• Version-skew failure: bundle assumptions against an unspecified MeiliSearch server generation — 404s or silently ignored settings. In Symfony this fails loudly at container boot; in any Laravel port it would fail late and obscurely at first query. Worst-case shape: silent, not loud.
• Settings drift: ranking/typo configuration changed on the server, relevance shifts, no code change, no error.
• Index drift: failed queued jobs leave stale documents; primary-key mismatch produces duplicates that look like data bugs.
• Reindex storms: full reimports blocking the queue during incidents.

Ramp-up. MeiliSearch's mental model — filterable vs. searchable attributes, ranking rules, the async task queue — takes a mid-level developer 1–2 days. The SDK is simple and well-documented. The bundle saves none of that learning, and the 0.1.0 republish adds a layer of "which version are these docs for" archaeology on top. Scout's conventions absorb most of the integration surface, so the team learns the search engine rather than someone's in-flight Symfony wiring.

Recommendation: do not adopt. The 0.1.0 release retires the "five years stale" objection and changes nothing else. It remains a Symfony bundle in a Laravel shop, at 11 stars and 0 dependents, now pre-1.0 with no support policy, an unspecified MeiliSearch server target, and a roadmap explicitly pointed at API Platform. Score 1.76, against a first-party Laravel path that is maintained, documented, and half-a-day to stand up. The 4.69 opportunity score is a signal about the search category, not this package. Take the category; leave the package. Re-evaluate only if it ships a framework-agnostic core and a 1.0 — and even then, we'd be comparing it to Scout, not replacing it.