# Meilisearch's JS plugins exist so you do not have to write the search client yourself

> meilisearch-js-plugins is a pnpm and turbo monorepo holding the search client that lets InstantSearch talk to Meilisearch, plus an Autocomplete client, and it sits alongside a wider set of connectors for Strapi, Firestore, Gatsby and docs sites. Two packages here, more in neighbouring repositories.

**meilisearch/meilisearch-js-plugins** — The search client to use Meilisearch with InstantSearch.

- Repository: https://github.com/meilisearch/meilisearch-js-plugins
- Website: https://www.meilisearch.com
- Stars: 533 · Forks: 70
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/meilisearch-meilisearch-js-plugins

## Two search clients, and a family of connectors elsewhere

The repository is described as containing clients and plugins to use Meilisearch with third party tools, and its title in the README is Meilisearch Javascript plugins. The repository description says it is the search client to use Meilisearch with InstantSearch.

The plugins table lists two packages that live here. instant-meilisearch is the search client for instantsearch.js, the Algolia library. autocomplete-client is the search client for autocomplete, also from Algolia.

That pairing explains the whole design. Both packages exist so that you can use a UI layer you may already know, without writing the part that turns a UI's search intent into a Meilisearch query and back. The topics list the consumers: angular, react, vue and instantsearch, alongside js, geosearch and meilisearch.

The table also lists plugins that live in other repositories, and the distinction is worth keeping straight. There is strapi-plugin-meilisearch for adding and synchronising Strapi collections, firestore-meilisearch for synchronising Firestore data, gatsby-plugin-meilisearch for indexing Gatsby content, docs-searchbar.js as a search bar integration for documentation of all kinds, and vuepress-plugin-meilisearch for using that search bar with vuepress.

So this repository is the client layer, and the connectors live next door. If you are evaluating Meilisearch integrations generally, you need more than one repository.

The licence is MIT, the primary language is TypeScript, the homepage is www.meilisearch.com, and the recent releases are all for the InstantSearch package, @meilisearch/instant-meilisearch at 0.31.4 on 2026-09-16, 0.31.3 in July and 0.31.2 in June. The last push to the repository was on 2026-09-30.

## A pnpm and turbo monorepo, with a playground per frontend

The repository top level is the modern JavaScript monorepo setup. There is a pnpm-workspace.yaml, a pnpm-lock.yaml, a turbo.json, a packages/ directory and a playgrounds/ directory, plus .changeset/ for release notes, .nvmrc for the Node version, an eslint.config.js, a .prettierrc.js, a tsconfig.json, a vite.config.ts and an AGENTS.md.

The scripts in package.json show how the pieces fit together, and the playground scripts are the most informative part.

```json
  "scripts": {
    "playground:vanilla": "turbo @meilisearch/vanilla-playground#dev",
    "playground:vue3": "turbo @meilisearch/vue3-playground#dev",
    "playground:react": "turbo @meilisearch/react-playground#dev",
    "playground:node": "turbo @meilisearch/node-playground#dev",
    "playground:autocomplete": "turbo @meilisearch/autocomplete-playground#dev",
    "build": "turbo build",
    "test": "vitest run",
    "release": "pnpm build && changeset publish"
  },
```

There are seven playgrounds, one per frontend flavour, including a local-react one that presumably talks to a Meilisearch running on your own machine, and a standalone one. The dev command for each is a turbo task invocation scoped to a single package, which is what makes the whole set runnable from one root command.

The build and test tooling is turbo for orchestration, Vitest for unit tests, and tsc for the type check. The test:types script is plain tsc, and there are two project-scoped watch commands, one for the InstantSearch package and one for the Autocomplete package, using the vitest --project flag. End-to-end tests run through turbo as well, with a separate watch variant.

Style is handled by Prettier and ESLint, and the composite scripts are named so that CI and a developer run the same thing. The style script runs fmt then lint, and style:fix runs the fixing variants of both.

The release path uses changesets, so version bumps and changelogs are generated from a .changeset/ directory rather than edited by hand.

## Node versions are pinned, and the mode is fixed

Two details in the root package.json are worth pulling out because they affect how you consume the packages rather than how you develop them.

The first is the type field.

```json
  "type": "module",
```

The workspace is ESM only. That is a deliberate choice for a package set shipping to modern bundlers, and it means the packages are consumed as ES modules. A CommonJS application that still resolves require() for dependencies will need a dynamic import or a bundler that handles ESM, and that is a real constraint on adoption in an older Node codebase.

The second is the engines field.

```json
  "engines": {
    "node": "^20.19.0 || >=22.12.0"
  },
```

So Node 20.19 or later in the 20 line, or 22.12 and above. The .nvmrc file at the repository root records the version the maintainers develop against, and the engines field records what the packages promise to support. Both exist so that a developer and a consumer agree on the floor.

The root package is private and marked as such, with the licence field set to MIT and the repository pointing at the GitHub URL. The private flag matters because the root is a workspace container, not something published to a registry. What gets published are the individual packages under the @meilisearch scope, which is why the release tags are named for @meilisearch/instant-meilisearch and not for the repository.

## Two ways to consume, and the difference between them

The two packages target different Algolia libraries, and the choice follows from your UI.

instant-meilisearch is the search client for instantsearch.js. InstantSearch is a set of UI components, widgets and a state model for building search interfaces, and it is the layer most teams reach for when they want a search box with filters, pagination and refinement lists. Replacing its search client with a Meilisearch one means the widgets stay and the query translation changes.

autocomplete-client is the search client for autocomplete, which is Algolia's newer search-as-you-type interface library. It is a different shape of thing: a dropdown of suggestions as the user types, rather than a results page, with its own plugins for query suggestions and tags.

The devDependencies at the root confirm the shape of the second package. They include @algolia/autocomplete-js, @algolia/autocomplete-core, @algolia/autocomplete-plugin-query-suggestions, @algolia/autocomplete-plugin-tags and @algolia/autocomplete-theme-classic, all at 1.19.8, plus @algolia/client-search at 4.24.0.

That dependency list is worth reading as a design statement. The Autocomplete client is not a from-scratch implementation, it is a Meilisearch-backed adapter that keeps the autocomplete-core abstraction and swaps the search client underneath. The theme package in particular indicates that the visual layer stays Algolia's, with the search behaviour underneath replaced.

The version numbers being pinned to exact patch versions rather than ranges is a consequence of that: the packages are tested against a specific version of the Algolia libraries, and the adapter's correctness depends on that interface not moving underneath it.

## Where the plugins stop and the rest of the ecosystem begins

The README's own framing is helpful here. For general information on how to use Meilisearch, such as the API reference, tutorials, guides and in-depth articles, it points at the main documentation website. This repository is about the client and plugin layer only.

That means two things for an evaluator. First, the mechanics of how the client maps an InstantSearch request onto a Meilisearch query are documented in the Meilisearch documentation site rather than in this repository, and the package README for the plugin itself is where the usage detail would be. Second, the search engine itself, the features, the ranking, the typo tolerance, the faceting, all of that belongs to the meilisearch repository rather than here.

The other half of the ecosystem is the integration-guides repository, which the README points to for anyone who wants to contribute, make suggestions, or just follow what is going on. The README is explicit that Meilisearch provides and maintains many SDKs and integration tools like this one.

There is also a hosted option in the same document. The README promotes Meilisearch Cloud with a 14-day free trial and no credit card required, positioned as a way to say goodbye to server deployment and manual updates.

That is a reasonable thing for a maintainer to say in their own plugin repository, but it is worth keeping in mind when reading any project documentation: the comparison between running the search engine yourself and using the hosted service is not a neutral comparison, because the documentation is written by the vendor of the hosted service.

## Where these plugins are the wrong choice

Three cases, and they are about the shape of the problem rather than about quality.

First, if you are happy with Algolia's own client. The whole value of these packages is that they let you keep an Algolia front end and swap the engine. If the front end is not something you use, or if you are happy calling Meilisearch's HTTP API directly, this layer is an extra dependency that translates requests for you and costs you a round trip through an abstraction.

Second, if your search needs are not a query-and-a-list. The InstantSearch model is a text query refined by filters, and the widgets are built around that shape: search box, refinement list, pagination, hits. If your requirement is geospatial search, the topics list mentions geosearch, and if it is faceting at scale, or typo tolerance tuned per index, the client package is not where that behaviour lives. It is in the engine and its configuration.

Third, if you cannot take an ESM dependency. The type module field means the packages are ESM, and an application that is CommonJS-only, with a bundler configured for CommonJS and an older toolchain, will need work before it can import them. The engines floor of Node 20.19 compounds that, because the older versions people often have pinned on legacy services are outside the range.

One practical note about the release cadence. The recent tags are all for the InstantSearch package, and the last one is 0.31.4 from 2026-09-16, with the last push on 2026-09-30. The Autocomplete client appears to move separately, on its own version line, so if you depend on both you are tracking two release streams.

## Conclusion

Adopt instant-meilisearch if you want InstantSearch's components and behaviour with Meilisearch as the engine, because the alternative is writing the request translation and index mapping yourself. Do not adopt it if you are on Algolia's own client and happy there, because the whole point of the package is to swap the backend. Verify first which of the two packages in this repository you need, since the InstantSearch client and the Autocomplete client are separate releases, and check the Node version your build uses, because the workspace declares node ^20.19.0 || >=22.12.0.

## FAQ

### What is in the meilisearch-js-plugins repository?

It contains clients and plugins to use Meilisearch with third party tools. The plugins in this repository are instant-meilisearch, the search client for instantsearch.js, and autocomplete-client, the search client for Algolia's autocomplete library. Other Meilisearch plugins, for Strapi, Firestore, Gatsby and docs sites, live in separate repositories.

### How is the Meilisearch JavaScript plugins repository built and tested?

It is a pnpm and turbo monorepo with a playground per frontend, vanilla, Vue 3, React, local React, Node, standalone and Autocomplete. The build uses turbo build, unit tests use vitest run, type checking uses tsc, and end-to-end tests run through turbo. Releases go through changeset publish after a build.

### What Node version do the Meilisearch JavaScript plugins need?

The root package.json sets engines node to ^20.19.0 || >=22.12.0, so Node 20.19 or later in the 20 line, or 22.12 and above. The root package is also marked as type module, so the packages are ESM only.

### What is the difference between instant-meilisearch and autocomplete-client?

instant-meilisearch is the search client for instantsearch.js, which provides search interface widgets such as refinement lists and pagination. autocomplete-client is the search client for Algolia's autocomplete library, which is a search-as-you-type dropdown, and the root devDependencies pin the autocomplete core, js, plugin and theme packages at 1.19.8.

## Sources

- [License: MIT](https://github.com/meilisearch/meilisearch-js-plugins/blob/main/LICENSE)
- [meilisearch/meilisearch-js-plugins on GitHub](https://github.com/meilisearch/meilisearch-js-plugins)
- [Project website](https://www.meilisearch.com)
- [README](https://github.com/meilisearch/meilisearch-js-plugins/blob/main/README.md)
- [Releases](https://github.com/meilisearch/meilisearch-js-plugins/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/meilisearch-meilisearch-js-plugins