ngx-mat-select-search: a filter input for Angular select fields

The missing piece in select fields: a filter for long option lists

Select controls with a hundred options are a common requirement and a common complaint. The standard select component from the Angular component library offers no built-in way to narrow the list by typing, so teams end up with three bad options: an autocomplete, a custom dialog, or nothing at all.

NgxMatSelectSearch is the third path, packaged as a drop-in component. The project describes itself in one sentence as an Angular component providing an input field for searching and filtering MatSelect options of the Angular Material library. The screenshot in the README shows the resulting interface: the select with a text input layered on top of it.

That framing tells you the intended scope precisely. It is a filter for the options of a select, not a search engine, not a virtual scroller, and not a replacement for the select control. For an application where a country or a product list is long enough that scrolling is painful, that is exactly the missing piece, and it is small enough to read in an afternoon.

The audience is Angular developers working with the Material component library who want the behaviour now rather than after it ships upstream.

A stopgap for an open upstream request, not a permanent home

The README carries a note that shapes how you should treat this dependency. The project states that it is meant as a temporary implementation of the long-standing upstream request in the Angular component library repository, issue 5697, and that the goal is to have an implementation in the official Angular Material repository, with a new pull request to be created.

This is unusual candour for a package README, and it is useful. It tells you two things at once. First, the behaviour you are adopting is one the maintainers of the component library themselves consider desirable enough to have an open issue for. Second, there is an intention to upstream it, which means the long-term home of this code may not be this repository.

For an engineering decision, that cuts two ways. If your team wants to influence where the official implementation ends up, using this package and reporting behaviour in the upstream issue is a reasonable way to participate. If your team wants a component with a multi-year support commitment, a package whose own author describes it as temporary is the wrong foundation, however good the code is.

The alternative worth naming is writing the filter yourself on top of the select's overlay, which is what the upstream request implies is not straightforward. That path costs you an ongoing maintenance burden and gives you full control over filtering semantics, at the price of reimplementing keyboard and focus behaviour that the component library already handles.

Version 9 and a peer dependency range covering Angular 17 to 22

The published package is version 9.0.0, and the peer dependency range is wide. The package metadata declares the library name, the current version and the licence together:

  "name": "ngx-mat-select-search",
  "version": "9.0.0",
  "license": "MIT",

The single peer dependency is the component library itself, and the range spans several major Angular versions:

    "@angular/material": "^17.0.0 || ^18.0.0 || ^19.0.0 || ^20.0.0 || ^21.0.0 || ^22.0.0"

A peer dependency range like this is a promise from the maintainer, not a guarantee from the compiler, and it is worth checking against the version you actually run. The range covers Angular 17 through 22, while the development dependencies sit at the 21.2 line, including the CLI, the build package, the cdk and the forms package. That means the library is developed and tested against a recent Angular, and the older versions in the range are compatibility claims rather than the primary target.

Because the peer dependency is a range rather than a pin, your installer will not stop you from pairing this with an Angular version the maintainer may never have run. A quick check of the changelog is a sensible precaution when you move between Angular majors, and the repository keeps a CHANGELOG.md at the root for exactly that.

Two demos: an editable StackBlitz and a prebuilt mobile page

The README offers two ways to see the component working, and they answer different questions.

The first is a StackBlitz example hosted at the ngx-mat-select-search-example repository, with a link that opens the example component's template file directly. The README describes it as example code that builds in the browser, on the latest version and the latest component library version. That is the better demo for evaluation, because you can read the template and the component side by side, change values, and watch the filter behaviour update without setting up a project.

The second is a prebuilt page on GitHub Pages, described as running the latest version against Material 21 and working on mobile. That is the one to open on a phone if you are evaluating a mobile form, since touch behaviour and viewport layout are where a filter overlay can go wrong.

What neither demo does is document the component's API. The README does not list the inputs, outputs or configuration options of the component, and it does not describe keyboard handling, how the filter matches text, or whether the behaviour differs for single and multiple selection. The example application is therefore the de facto API documentation, which is a normal pattern for small component libraries but does mean you should budget time to read it.

The npm package page is where the install and version information lives, linked from the version badge at the top of the README.

How the package is built and released

The repository is a standard Angular workspace, and the scripts describe the whole lifecycle. Development is ng serve, the production build is ng build with the production configuration, and the library itself is packaged with ng-packagr against an ng-package.json file. That last script is the one that matters if you want to understand how the distributable is produced, since a component library is compiled with the partial-compilation pipeline that ng-packagr applies rather than with a plain application build.

Continuous integration is CircleCI, with a config directory at the repository root, and there is a dedicated CI build variant that overrides the base href to /ngx-mat-select-search/, which is what makes the GitHub Pages demo work when it is served from a subdirectory. A separate CI test script exists for the same reason: running the suite in a non-watch mode inside a pipeline rather than on a developer machine.

Linting is configured through eslint.config.mjs, and the workspace has separate TypeScript configurations for the app, the library and the specs. The default branch is master rather than main, which is a small inconsistency with current convention and worth knowing if you write automation against this repository.

Contributions are invited through issues and pull requests, and the README asks for financial support for the maintenance work, with a list of named financial supporters and a contributor list maintained in the README itself.

Release cadence, the 8.x to 9.x jump, and what the licence allows

The release history shows steady maintenance with a recent major bump. Version 8.0.5 was published on 2026-05-08, 8.0.6 followed on 2026-05-14, and 9.0.0 arrived on 2026-07-14. The last push to the repository was on 2026-10-08, and the repository is not archived, so the work continues between releases.

That 9.0.0 jump is the item to look at before you upgrade, because a major version in a small library usually means a breaking change in the component API. The CHANGELOG.md in the repository is the place to see it, and the project asks contributors to open an issue and preferably a pull request, so behaviour changes tend to be discussed before they land.

The licence is MIT, with the LICENSE file at the repository root and the same identifier in the package metadata. MIT permits use in commercial applications, modification and redistribution, with the requirement that the copyright notice and licence text travel with the code. For a component that many teams would embed in a product, that is a low-friction licence.

One practical caveat on upgrades: the package follows the component library's major versions, so your upgrade path is coupled to Angular's own release cycle. A team on an old Angular release will find themselves pinned to an old major of this package, and the range of supported Angular majors in the peer dependency is the practical limit on how long that pinning lasts.

Editorial conclusion

ngx-mat-select-search is a reasonable dependency for an Angular team that needs filtering on a long select today and does not want to write its own overlay, and the MIT licence and wide peer dependency range make it cheap to try. It is the wrong choice if you need multi-select filtering, server-side search or documented keyboard behaviour, because the README does not describe those features, and it is the wrong choice for a long-lived product if an upstream version lands. Before adopting it, read the CHANGELOG.md for the breaking changes between 8.x and 9.x, check that your Angular version falls inside the supported peer range, and open an issue if the upstream request matters to you.

Frequently asked questions

Official sources

1. bithost-gmbh/ngx-mat-select-search on GitHub
2. Issues
3. License: MIT
4. README
5. Releases