Graphql Files Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for GraphQL file uploads. The entire scope of this package is narrow: it bridges the GraphQL multipart request spec into mutation arguments on the youshido-php GraphQL stack. That is a small, well-understood piece of plumbing — the kind of thing a team can scope in a day or two. The real decision it informs is "do we take a dependency for ~200 lines of request parsing, or write it ourselves?"
• API architecture: one endpoint or two. Whether file-bearing operations (avatar upload, ticket attachment, CSV import, CMS media) go through GraphQL mutations or through a dedicated REST/S3 presigned-URL path. This is a genuine product-architecture fork with downstream consequences for client complexity, CDN integration, and mobile retry behavior.
• Stack-level bet, not package-level bet. Adopting this bundle implies adopting youshido/graphql as the GraphQL engine. That's the strategic decision worth escalating; the bundle itself is incidental.
• What it does not support: demand validation. Four stars and zero dependents is an absence of signal, not a positive one. Do not cite this package in a roadmap doc as evidence that GraphQL-native uploads are a market need — the need may well be real, but this repo tells you nothing about it.
• Reference material. Its most defensible use is as a reading reference for how the multipart spec maps onto a PHP resolver — useful if you build your own.

When to Consider This Package

Consider it only if all of the following hold:

• You are already committed to youshido/graphql on a Symfony application. Note the mismatch in the brief: this is a Symfony bundle, not a Laravel package — there is no service provider, no config/graphql.php, no Laravel integration. Dropping it into Laravel is not a supported path.
• The app is legacy and you cannot justify a migration to a maintained GraphQL layer for this one feature.
• You need the GraphQL multipart request spec handled quickly and are willing to vendor or fork the code, since upstream responsiveness is unlikely.
• Your upload requirements stop at "receive the file and hand it to application code" — no virus scanning, no direct-to-S3, no resumable uploads, no image transformation.

Look elsewhere if any of these are true:

• You are on Laravel. Use Lighthouse's upload support, or a webonyx/graphql-php-based stack with an established upload implementation. This is the common case and this package is not it.
• You need maintenance guarantees. Low stars, zero dependents, and a thin commit history mean no security patch SLA, no PHP 8.x compatibility commitment, and no one to escalate to. For anything customer-facing or handling PII, that is disqualifying on its own.
• You want batteries included. Validation, storage abstraction, size limits, and content-type filtering all land on you.
• Greenfield work. Starting a new API on a stack with this adoption profile is a hard sell in any architecture review.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source component that would let clients upload files through our GraphQL API. Technically it does one thing competently, but it has effectively no adoption — four stars, zero dependent projects, no visible maintenance — and it targets Symfony while our application is Laravel. Recommendation: do not adopt. Either we implement the equivalent logic in-house, which is a small, bounded piece of work we fully control, or we standardize on the maintained GraphQL library already used across the Laravel ecosystem. The cost of the alternative is measured in days; the cost of adopting an unmaintained dependency is measured in an eventual forced migration plus whatever support burden accrues in between.

To engineering: The bundle is a thin adapter for the GraphQL multipart request spec on the youshido-php stack. Its single virtue is that it is small enough to read in an afternoon and copy outright. Its problems are structural: wrong framework, no community, no upgrade path, and a transitive bet on a GraphQL engine we are not otherwise using. Proposal: treat it as a design reference, not a dependency. If we need GraphQL uploads, we implement against the published multipart spec on our existing stack — roughly a sprint task, with tests — and we keep ownership of the edge cases (size limits, content-type allowlisting, storage backend) rather than inheriting an unmaintained version of them.