meilisearch
Laravel Scout after meilisearch-php v2
Due to the breaking changes planned in v2, we need to map and provide a PR to Laravel Scout integration. This issue is mostly a reminder :)
At the first look, I don't see anything that in https://github.com/laravel/scout/blob/10.x/src/Engines/MeilisearchEngine.php something would break after my PR, unless you are planning additional bc breaks 🤔
Thank you for opening this issue! I would avoid doing any breaking that will impact the laravel package, unless it's extremely necessary
As of 2.0.0-beta.1, Meilisearch PHP v2.x introduces breaking changes that affect Laravel Scout.
While most of Scout's internal operations (adding/deleting documents) are compatible because Scout ignores their return values, direct "passthrough" methods exposed by the src/Engines/MeilisearchEngine.php—specifically createIndex and deleteIndex—will now return a Meilisearch\Contracts\Task object instead of an array.
This is a breaking change for any developer using these specific methods in their application code expecting an array response (e.g., to check taskUid).
Moving forward
To support Meilisearch PHP v2.x in Laravel Scout, we would need to Handle Return Types:
We have two options for createIndex and deleteIndex:
* Option A (Breaking): Allow them to return Meilisearch\Contracts\Task and document the breaking change.
* Option B (Compatible): Manually convert the Task object to an array within MeilisearchEngine to preserve the v1 signature. Note that the v2 Task object does not implement Arrayable or toArray(), so we would need to manually map properties like taskUid, status, etc., to an array.
My recommendation is to go with Option B to avoid any breaking changes for Laravel users.
NB: We can open an issue on Scout to improve typing in Scout later on, but I don't think this should be our main focus. I don't know of Laravel users having any expectations in that regard.
That's why we have semver, no?
MAJOR version when you make incompatible API changes
As far as direct meilisearch-php users are concerned, there are no issues.
But we want to avoid introducing breaking changes in Laravel Scout if possible, so they can adopt the v2 SDK.
From my understanding, Option B would be a minor change on our end, which doesn't remove any of the improved DX for our users, right?
Well if you mean making a PR to update their engine so it will work for them either v1 or v2 ? then i agree. otherwise i don't understand your intentions
My proposal would be to:
-
Update Meilisearch PHP to add a
toArray()method toMeilisearch\Contracts\Taskclass (returns the raw array 🥲) -
Make a PR to Laravel Scout to handle v2, e.g.:
public function createIndex($name, array $options = [])
{
$response = $this->meilisearch->createIndex($name, $options);
// Check if we are running on v2 (returning an object)
if ($response instanceof \Meilisearch\Contracts\Task) {
return $response->toArray(); // Converts back to array for BC
}
return $response; // Fallback for v1 (already an array)
}
What do you think?
I'm happy to take suggestions, maybe there's a better way to approach this.