Doctrine Entity Search Bundle Laravel Package

Product Decisions This Supports

• Search feature feasibility for Doctrine-backed PHP services: This bundle is a reference implementation of entity search over Doctrine ORM entities. It informs whether to build search into an existing Doctrine/Symfony service layer or delegate to a dedicated search engine (Elasticsearch, Meilisearch, Typesense, Algolia).
• Build vs. buy vs. wire-up: The package is a thin adapter layer — a "wire-up" option. It supports the decision of whether a small internal search capability is worth maintaining in-house versus integrating a managed search product.
• Architecture choice for search indexing strategy: Because it is Doctrine-based, it implies an ORM-entity-centric indexing model. That directly informs the product decision between "search the database" (simple, cheap, weak relevance) and "maintain a separate search index" (better relevance, operational cost).
• Laravel vs. Symfony stack alignment: This is a Symfony bundle and is not a Laravel package. The most important PM decision it supports is not adopting it in a Laravel codebase and instead evaluating Laravel-native equivalents (Laravel Scout, TNTSearch, Meilisearch drivers).
• Roadmap input — search maturity tiers: Useful as a benchmark artifact when scoping a search roadmap: tier 0 (SQL LIKE), tier 1 (Doctrine entity search adapter), tier 2 (dedicated search engine with faceting, ranking, synonyms).
• Risk register: Zero stars, zero dependents, single-vendor maintenance, and a Score of 0 make this a supply-chain and maintenance risk line item, not a capability line item.

When to Consider This Package

Consider it only if all of the following hold:

• The codebase is Symfony, not Laravel, and already uses Doctrine ORM as its persistence layer.
• You need a narrow, low-complexity search capability — filtering and keyword lookup over a handful of entities — not relevance-ranked, faceted, or multilingual search.
• You are comfortable vendoring or forking the bundle: with zero stars and zero dependents, assume no upstream support, no security patching cadence, and no community answers.
• Apache-2.0 licensing is acceptable for your distribution model (it generally is; attribution obligations apply).
• You have engineering capacity to read and own the source — treat it as sample code you adopt rather than a dependency you consume.

Look elsewhere when:

• Your stack is Laravel. This package will not integrate cleanly; use Laravel Scout with a TNTSearch or Meilisearch driver instead. This is the dominant case for a Laravel/PHP audience.
• You need production-grade search: relevance tuning, typo tolerance, faceting, highlighting, synonyms, or scale beyond a single database.
• You require vendor support, SLAs, or a security disclosure process — none of which a zero-star, zero-dependent package provides.
• Your search requirements are growing; a Doctrine-coupled adapter becomes migration debt the moment you move to a real search engine.
• You want a maintained dependency; a single-vendor bundle with no dependents is effectively unmaintained by default.

How to Pitch It (Stakeholders)

For executives: A small open-source component has surfaced that implements entity search on top of Doctrine, the data layer used by Symfony applications. It is architecturally interesting but commercially immature: no adoption, no community, no support path. The recommendation is not to adopt it as a dependency. Its value to us is as a design reference for how search can be layered onto an existing ORM — useful input to a build-vs-buy decision, not a component to ship. Net cost of adoption is low in licensing terms (Apache-2.0) and high in ownership terms, since we would effectively maintain a fork.

For engineering: This is a Symfony bundle, not a Laravel package, so it is out of scope for our Laravel services. Where we do run Doctrine, the pattern is straightforward: map entities to a search index and query through an adapter. We can reproduce that pattern in a few hundred lines tailored to our domain, or — better — invest in a dedicated search engine via Laravel Scout or a Meilisearch/Typesense integration. Treat this repository as prior art. If anyone wants to prototype with it, do so in a spike branch, pin the commit, and record the fork point; do not add it to a production composer.json.

For product: The existence of this package confirms that "basic entity search" is a solved, commoditized problem — it should not appear on a roadmap as a differentiating initiative. What remains genuinely valuable is search quality: relevance, ranking, and retrieval UX. Scope roadmap effort against quality and user outcomes, and let the underlying indexing mechanism be an engineering implementation detail.