Goat Query Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a user-facing filter/query layer. If the roadmap contains "advanced search," "saved filters," "custom report builder," or an admin query console, this package is one data point in the build-vs-buy analysis — and it lands on the build or buy-something-else side.
• Framework alignment correction. The premise says Laravel/PHP, but this is a Symfony bundle (Goat Query Symfony bundle). Any adoption would require a Symfony service container and bundle registration; in a Laravel codebase it is at best a source of design ideas, never a drop-in dependency. That reframes the decision from "install or not" to "study or ignore."
• Design reference for a declarative query DSL. The genuinely reusable artifact is the pattern: describe allowed fields/operators as typed metadata, parse an untrusted filter payload into a validated query object, and keep the query definition independent of the transport (HTTP, CLI, GraphQL). If we are scoping an in-house filtering layer, a half-day read of this codebase is cheaper than a whiteboard debate.
• Security/validation posture decision. Any feature that accepts user-authored query syntax must decide who owns parsing, allow-listing, and injection defense. This package demonstrates one approach; the decision of whether we want to own that surface is a product-risk decision, not a library choice.
• Licensing and supply-chain policy input. GPL-2.0 with zero dependents and zero stars makes this a useful concrete test case for whether our dependency policy (copyleft review, maintenance thresholds, CVE response expectations) actually gets enforced in practice.
• Roadmap de-prioritization. Nothing here justifies a roadmap item. The correct output of the evaluation is a documented "no," which prevents a future engineer from re-litigating the same spike.

When to Consider This Package

Consider it only as a reading reference, or as a dependency under all of the following conditions simultaneously:

• The product is a Symfony application on a compatible PHP version — not Laravel, not a framework-agnostic service.
• The product is itself distributed under GPL-2.0-compatible terms, or is strictly internal and never distributed to third parties and legal has signed off on the interpretation. Copyleft in a distributed commercial product is a dealbreaker, full stop.
• The team is prepared to own and maintain a fork indefinitely: no upstream activity, no security response, no issue triage, no guaranteed PHP-version bumps.
• The feature is internal/back-office only, low blast radius, and does not sit on a customer-facing auth or tenancy boundary.
• There is a concrete, time-boxed need for a query DSL this quarter and a build estimate that exceeds the cost of adopting plus forking.

Look elsewhere — or build — when any of these are true:

• You are on Laravel. Use Eloquent scopes, query-builder constraints, Spatie Laravel Query Builder, or Laravel Scout. Reaching across ecosystems for a Symfony bundle is pure cost.
• The product is commercially licensed or SaaS with proprietary code. GPL-2.0 forces a legal conversation you do not want to have over a package with 0 stars.
• You need a support SLA, security patches, or CVE notification. There is no maintainer capacity to lean on; dependents: 0 means no one else is finding the bugs before you do.
• The feature is customer-facing or internet-exposed. A user-supplied query parser is an attack surface; you want actively maintained code or your own audited implementation.
• You need a decision in under a week. Evaluating an unmaintained package costs more in due diligence than writing a constrained allow-listed filter parser on top of the ORM.

How to Pitch It (Stakeholders)

To executives: We evaluated an open-source query-builder bundle to see whether it could accelerate our advanced-search/reporting roadmap. Recommendation: do not adopt. It is an unmaintained Symfony component with no user base, no security response, and a GPL-2.0 license that creates real legal exposure for a distributed commercial product. Cost to adopt safely (fork, audit, maintain) exceeds the cost to build a narrow version of the same capability ourselves. The upside is limited: it doesn't accelerate anything we can't do in a sprint.

To engineering: Treat it as a design reference, not a dependency. Budget at most a half-day skim if we greenlight an in-house filter DSL — the useful takeaway is the typed-field-metadata + parsed-query-object pattern, which we'd reimplement idiomatically in Laravel anyway (query scopes plus an allow-list of filterable columns and operators). Do not add it to composer.json; the GPL-2.0 license and absence of a maintainer make the total cost of ownership strictly negative.

The one-line version: zero adoption, copyleft license, wrong framework, no maintainer — good pattern, bad dependency.