Graphql Files Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package. It ships as a bundle class with a DependencyInjection extension and configuration tree, and is designed to be registered in AppKernel/bundles.php. Laravel has no concept of bundles, so there is no ServiceProvider, no config/*.php publishable config, and no facade — the integration surface a Laravel TPM would normally rely on simply does not exist.
• Its core value proposition — mapping .graphql query documents to PHP handler classes via filesystem convention — is conceptually compatible with Laravel (Laravel already leans on convention-based discovery), but the implementation is bound to Symfony's HttpKernel, DI container, and routing/event components rather than to Laravel's container and router.
• It sits on top of youshido/graphql, a resolver library that is effectively unmaintained (last meaningful releases in the 2017–2018 window). That dependency, not the bundle, is the real architectural decision, because it determines the schema/execution model your whole API would be written against.

Integration feasibility

• Practically infeasible without a fork or an adapter layer. You would need to: translate the bundle's DI configuration into a Laravel service provider, replace Symfony event-dispatcher hooks with Laravel middleware/pipelines, and reimplement the request-to-query resolution on top of Laravel's router and container.
• Because the bundle is small and low-traffic (4 stars, 0 dependents), the adapter would be 100% bespoke and unowned upstream — you would be maintaining a compatibility shim indefinitely with no community to share the cost.
• Composer constraints are the hard blocker: transitive Symfony 2/3-era component constraints and PHP version bounds will collide with any current Laravel (10/11/12) on PHP 8.2+. Expect dependency resolution to fail before you write a line of adapter code.

Technical risk

• Abandonment risk: very high. Zero dependents is the strongest available signal — no downstream projects exercising the code, no issue traffic, no implicit regression testing. Both the bundle and its schema library are dormant.
• Security/maintenance risk: high. No upstream patch path for CVEs in the GraphQL execution layer or the Symfony components it pins. Any vulnerability becomes your incident.
• Talent/onboarding risk: high. No engineer on a typical Laravel team will have seen this stack; GraphQL-in-Laravel knowledge is concentrated in Lighthouse and rebing/graphql-laravel.
• Fit risk: high. The convention-based file-to-resolver mapping is genuinely nice DX, but it is available from better-maintained sources — Lighthouse's @field directives and schema-first workflow deliver comparable ergonomics with an active maintainer and a large user base.

Key questions

1. What specific capability does this bundle provide that Lighthouse or rebing/graphql-laravel does not already cover on a modern Laravel stack?
2. Is there a business reason to stay on the Youshido execution model (existing schemas, existing resolvers), or is this a greenfield decision?
3. If the file-convention DX is the actual requirement, can we replicate it in ~200 lines as an internal package over webonyx/graphql-php rather than adopting an unmaintained transitive stack?
4. Who owns the fork, and what is the SLA for patching security issues in a dependency with no upstream?
5. Does our platform standard allow any package with zero dependents and no release in multiple years? (Almost certainly it should not.)

Recommendation: reject. Score 0.12 is consistent with the evidence. This is a reference implementation of an interesting idea, not a production dependency.

Integration Approach

Stack fit

• Poor. Target stack is Laravel + PHP 8.2+ with Composer 2; this package targets Symfony 2/3 + PHP 5.5/7.x. There is no overlapping supported version window.
• The only realistic "integration" is a fork: strip the Symfony bundle wiring, keep the file-convention resolver logic, rebind it to Laravel's container and router, and re-point it at webonyx/graphql-php. At that point you have written a new package and inherited a legacy one.

Migration path

• Preferred path: do not adopt. Start on Lighthouse (schema-first, directive-driven, Laravel-native) or rebing/graphql-laravel (thin wrapper over webonyx/graphql-php) and, if the file-based resolver convention is a stated requirement, implement it as a small internal convention layer on top.
• Contingency path, if a legacy Youshido schema must be preserved: isolate the Youshido execution behind an internal interface (SchemaExecutor), run it in a sidecar or legacy PHP container, and front it with the Laravel gateway. This buys time for a rewrite without contaminating the main application's dependency graph.
• Explicitly avoid: composer require into the main application. The dependency graph damage is not reversible without a rewrite.

Compatibility

• Blocks on three axes simultaneously: PHP version, Symfony component versions, and the abandoned youshido/graphql execution library. Any one of these is sufficient to fail; all three must be resolved, and two of them require upstream changes that will not arrive.
• No Laravel/Lumen version is supported. No PHP 8 typed-property/union-type/attribute support in the dependency chain.

Sequencing

1. Week 1 — spike & kill decision. Attempt a throwaway install in a scratch container against our target PHP version. Document the exact constraint failures. This produces the evidence for the rejection memo and costs under a day.
2. Week 1 — requirements extraction. Write down what the team actually liked about the package (file-per-query, convention-over-config, colocation of query text and resolver). This is the real requirement; the package is one implementation of it.
3. Week 2 — alternatives bake-off. Lighthouse vs. rebing/graphql-laravel against the extracted requirements. Include a 1-day prototype of the file-convention layer over whichever wins.
4. Weeks 3+ — standard adoption. Proceed with the chosen alternative through normal architecture review; the internal convention layer, if still wanted, becomes a small owned package with its own tests.

Operational Impact

Maintenance

• Upstream maintenance is effectively zero: no releases, no issue triage, no security response. Every fix is a fork-and-carry, including transitive Symfony and GraphQL-parser patches.
• Our team would own the entire stack — bundle, schema library, and compatibility shim — for a component with 4 stars and no other consumers to share defects with.
• Estimated ongoing cost: non-trivial and unbounded, dominated by security patching and PHP-version upgrade work that upstream will never do.

Support

• No vendor, no maintainer responsiveness, no community channel. Internal escalation path terminates at whoever volunteered to fork it.
• Debugging requires reading Symfony 2/3-era bundle source with no documentation beyond the README; expect long mean-time-to-diagnosis for schema-resolution issues.

Scaling

• The bundle's role is request-time query resolution, not data access, so it is unlikely to be the throughput bottleneck itself. Scaling concerns are indirect: no support for modern PHP opcache/JIT improvements (PHP 8 features unavailable), no async/persistent-server (Swoole/RoadRunner/Octane) compatibility, and no instrumentation hooks compatible with current OpenTelemetry Laravel packages.
• Horizontal scaling is fine in principle — the resolver mapping is stateless — but you would be scaling a PHP 7-era runtime, which caps the benefit.

Failure modes

• Dependency-resolution failure at install time — most likely outcome; surfaces immediately and cheaply.
• Silent runtime breakage on PHP 8 — deprecations turning into errors, untyped null propagation in the resolver chain, and each()/create_function()-class removals in the Symfony 2/3 components.
• Security exposure in GraphQL execution — query-depth/complexity limits, introspection controls, and batching protections in youshido/graphql predate current best practice; expect to hand-roll mitigations.
• Knowledge cliff — a single engineer becomes the only person able to debug schema resolution; bus factor of one.
• Fork drift — once forked, no clean path back to upstream (there is no upstream), so the fork becomes permanent by default.

Ramp-up

• Initial ramp-up looks deceptively low (small codebase, simple convention), which is the trap: the adoption cost is days, the ownership cost is years.
• Realistic ramp-up for a team to be productive and safe on this stack: 2–4 weeks of GraphQL-on-Laravel fundamentals plus the fork, with the caveat that "safe" is unachievable given the absence of a security patch path.
• Contrast with Lighthouse/rebing: hours to first schema, days to production, with a large hiring pool and active documentation. The productivity delta alone justifies rejection independent of the risk case.