Product Decisions This Supports
- Build vs. buy for input validation on GraphQL mutations. This package is best treated as a reference design, not a dependency. The core capability—declarative rules defined once, enforced before resolvers, and surfaced as structured GraphQL errors—is a pattern your team can implement in-house in a few hundred lines against Laravel's existing
Validator. That comparison is the real decision this package informs: the feature is cheap to build, so "buy" only makes sense if the maintenance burden is genuinely offloaded, which the adoption signals do not support.
- Reusable validation layer for GraphQL APIs. If your roadmap includes multiple GraphQL mutations across squads, the pattern (attribute/annotation-driven rules, centralized error mapping, nested array rule support) directly maps to a shared internal package or trait. This is the highest-value takeaway regardless of whether you install the library.
- API error-contract consistency. Automatic conversion of validation failures into well-formed GraphQL errors is a product-facing decision about API ergonomics and client-side error handling. Use this package's approach as a benchmark when defining your error schema, and as a prompt to standardize it before more mutations ship.
- Roadmap and runtime posture. The only documented change in the final release is PHP 7.3 compatibility (Jan 2021). That makes this a signal about your stack: if your Laravel app still pins EOL PHP, this package is a data point in the modernization backlog conversation, not a feature decision.
- Adoption-risk calibration. Zero stars, zero dependents, no releases since 2021, and a single unproven changelog entry. This is a useful input for codifying a "minimum health bar" for third-party packages (maintenance cadence, CI evidence, supported runtime matrix) so future build-vs-buy calls aren't made case by case.
When to Consider This Package
Adopt only under narrow conditions:
- You are maintaining a legacy Laravel application pinned to PHP 7.3 (or an era-appropriate Laravel version), you already have GraphQL mutations in production, and you have a documented plan and date to move off 7.3.
- You need a stopgap to remove scattered manual guard clauses from mutation classes quickly, and the alternative—writing the validation layer yourself—would slip a committed deliverable.
- You have verified Composer constraints against your actual Laravel/PHP versions, confirmed service-provider/config publish steps, and tested the install in staging rather than assuming compatibility from the name or description.
- You have accepted ownership of the code: no upstream fixes should be expected. Forking or vendoring is the realistic operating model.
Look elsewhere (or build in-house) when:
- Your stack is on modern PHP/Laravel. The package adds no capability your framework doesn't already give you, and it increases exposure to an EOL runtime constraint.
- You need test coverage evidence, a support policy, or a maintained changelog before taking a dependency—none is present here.
- Security review or procurement requires an active maintainer, CVE responsiveness, or usage by other teams (0 dependents is a hard fail for most such gates).
- You want a Symfony integration: despite the "bundle" naming, the described integration is Laravel's validator. Validate the actual framework target before assuming either way.
- The validation logic is non-trivial or domain-specific—at that point an internal implementation gives you better control, testability, and no version-pin conflict with your PHP upgrade path.
How to Pitch It (Stakeholders)
For executives: We evaluated a small open-source library that validates GraphQL mutation inputs before they reach application code. The capability is genuinely useful—it standardizes how malformed requests are rejected and how errors are returned to clients—but the library itself is not a sound dependency: last release was January 2021, its only documented change was PHP 7.3 support, and it has no measurable adoption. Recommendation: do not adopt as a dependency; instead direct engineering to implement the same pattern internally using Laravel's existing validator. This captures the benefit at low cost, avoids carrying an unmaintained component tied to an end-of-life PHP runtime, and removes a future blocker from our platform upgrade.
For engineering: The design is worth copying—declarative rule definitions (attributes, annotations, or config), automatic translation of validation failures into structured GraphQL errors with per-field messages, nested/array rule support, and no overhead on happy-path mutations. Build this as a thin internal package or trait. Before any adoption decision, resolve the open questions: which Laravel versions are supported, what are the PHP min/max constraints, is PHP 7.3 covered by CI, and does the release preserve compatibility with current PHP? One release note is not sufficient evidence of either compatibility or stability.
What we are not saying: This is not a criticism of the author's work—it is a maintenance and risk position. If the package is later revived with CI, a supported-version matrix, and a support policy, revisit. Until then, treat the repository as prior art, not as a component of our platform, and use it as the trigger to publish a minimum health bar for third-party dependencies so this evaluation doesn't have to be redone per package.