Goat Query Laravel Package

Product Decisions This Supports

• Data-access build vs. buy. Informs whether to invest engineering time in a custom typed query builder versus leaning on Laravel's Eloquent/Query Builder or Doctrine DBAL. Goat's architecture (fluent SQL builder layered over a bidirectional PHP↔SQL type converter) is a useful reference point for scoping that work, even if the package itself isn't adopted.
• Typed abstraction scope. If we have an epic around type-safe database access — enums, value objects, custom column types, legacy schemas that don't map cleanly to Eloquent casts — this is a concrete example of what a standalone typed builder API looks like and where the conversion edge cases live.
• Legacy and non-Eloquent integration. The PHP↔SQL converter half is relevant to reporting, ETL-ish jobs, imported schemas, or services where models aren't Eloquent. It informs whether we need a dedicated type-mapping layer or can rely on existing casts and DBAL types.
• Distribution/licensing constraints. GPL-2.0 is a product-level decision, not just a legal footnote. Using it affects whether we can ship a closed-source application, offer a hosted service, or redistribute a package. It forces an explicit answer to "is our product GPL-compatible?"
• Dependency risk posture. 2 stars and 0 dependents is a decision input for our dependency policy — it establishes that this sits in the "reference material / spike" bucket, not the "add to composer.json" bucket.

This package is unlikely to drive roadmap priorities. It's a discovery input for one technical decision, not a feature-enabler.

When to Consider This Package

Consider it when:

• We are building or maintaining a GPL-compatible open-source project and the copyleft terms are acceptable.
• We need a standalone SQL builder outside Laravel — a CLI tool, a microservice, an internal batch job — and Eloquent's coupling to the framework is genuinely in the way.
• We are running a spike or design review for our own typed query builder and want to study a small, readable implementation of PHP-to-SQL type coercion.
• We have a narrow legacy schema where mapping PHP types to SQL types manually is the dominant cost, and we want a library-shaped prototype to validate the approach.

Look elsewhere when:

• The product is closed-source, SaaS, or commercially distributed. GPL-2.0 is disqualifying without a deliberate legal decision, and even then the cost rarely justifies it.
• We are Laravel-native. Eloquent, the query builder, attribute casts, and custom cast classes already cover the type-mapping use case with vastly more documentation, community, and long-term support.
• We need maintenance guarantees. Two stars, zero dependents, and a single-maintainer footprint mean no security patches, no compatibility guarantees, and no one to escalate to. That is a real operational liability, not a stylistic concern.
• Mature alternatives fit the same need: Doctrine DBAL, Cycle ORM, Aura.SqlQuery, Laminas\Db. These occupy this exact niche with active maintenance, and picking any of them is a lower-risk decision than picking this.
• We need production essentials — connection pooling, schema introspection, robust prepared-statement handling, driver coverage — which a small experimental builder should not be expected to provide.

The low opportunity score and near-zero adoption reinforce the same conclusion: this is a read-and-learn candidate, not an adoption candidate.

How to Pitch It (Stakeholders)

For executives: We evaluated makinacorpus/goat-query, a small SQL query builder with a PHP-to-SQL type converter. Recommendation: do not adopt. Three reasons. First, it is GPL-2.0 licensed, which would force us to open-source our application or absorb a legal review — a cost with no offsetting benefit. Second, it is effectively unmaintained: two stars, zero dependents, no community to rely on for fixes or security patches. Third, the problem it solves is already solved inside Laravel by Eloquent and its type-casting system, which we already pay for and already support. Adopting this would add risk and remove nothing from our plate.

For engineering: Treat it as reference material only. It's a compact illustration of how to separate a fluent query builder from a bidirectional type converter — worth twenty minutes if we ever scope a custom typed data-access layer or a standalone service outside Eloquent. If that need becomes real, the shortlist is Doctrine DBAL or a thin wrapper over Laravel's schema and query builders, not this. Please do not add it to composer.json; if someone wants to prototype with it, do so in a throwaway branch and record the outcome as a decision note so we don't relitigate it.

Bottom line: research-only, no adoption, no dependency. The durable output of evaluating it is a documented decision on our licensing stance and our default for typed data access — both of which are worth having written down regardless of what happens to this package.