- What is garlic/graphql-php-tools and what problem does it solve?
- It is a small toolkit layered on top of webonyx/graphql-php that reduces boilerplate when defining schemas, registering types, and wiring resolvers. It targets the repetitive parts of building a GraphQL API by hand, such as field definitions, argument binding, pagination patterns, and consistent error handling. The package is framework-agnostic and can be used in plain PHP, with Laravel-friendly integration points provided.
- How do I install garlic/graphql-php-tools with Composer?
- Install it with composer require garlic/graphql-php-tools, which will also pull in its graphql-php dependency. Because the last tagged release dates to February 2019, run the install against a branch first and inspect what Composer actually resolves in your composer.lock rather than trusting the declared version ranges. Pin the resolved versions before merging anything into your main branch.
- Does garlic/graphql-php-tools support PHP 8 and Laravel 10 or later?
- There is no evidence of official support: the most recent release predates PHP 8, current graphql-php majors, and modern Laravel versions. Its 2019-era constraints may resolve to versions that no longer work, or may fail to resolve at all. Treat PHP 8.1+, Laravel 10+, and graphql-php v15+ as unsupported until you prove otherwise in a lockfile-resolved install and a working test suite.
- Can I use garlic/graphql-php-tools with Lighthouse or a custom GraphQL controller?
- In principle yes, since it is a thin utility over webonyx/graphql-php and does not dictate how you execute queries. In practice, Lighthouse ships its own SDL-first directive system, so the helper layer mostly matters for custom controllers or code-first schema construction. Verify that your Lighthouse version uses a compatible graphql-php major before assuming either path works.
- What does the schema merge actually do, and how are duplicate types resolved?
- The repository describes merging multiple schemas and extending an existing schema, but the exact semantics are not documented: it could be SDL concatenation, AST transformation, or type-registry deduplication. Duplicate type definitions and conflicting fields may error, take last-wins, or be silently overridden, and that behavior is the single biggest correctness risk. Read the source and write contract tests for directives, interfaces, unions, and extend type blocks before relying on it.
- Is garlic/graphql-php-tools safe to use in a production Laravel application?
- Not without ownership. The package has roughly one star, zero dependents, and no release since 2019, which means no security advisories, no upstream fixes, and no community to surface edge cases. If you adopt it, fork it under an internal namespace and assign a named maintainer who reviews it on every PHP, Laravel, and graphql-php upgrade. For most teams a native composition approach is the lower-risk choice.
- Is there a maintained alternative for composing GraphQL schemas in Laravel?
- Yes. You can compose schemas natively with graphql-php's schema type merging, use extendType blocks, or adopt a code-first builder instead of a merge utility. At the gateway layer, schema stitching or Apollo Federation cover multi-service composition. All of these are actively maintained, which makes them safer defaults than a 2019 single-author package.
- How should I evaluate garlic/graphql-php-tools before adopting it?
- Run a time-boxed spike on a throwaway branch: install it, compose two real module schemas, and diff the resulting type map and printed SDL against what you expect. Check the actual resolved PHP, Laravel, and graphql-php versions in your lockfile rather than the package's declared ranges. If the output matches, fork it; if not, fall back to native composition instead of forcing the dependency.
- Does garlic/graphql-php-tools include pagination and error handling helpers?
- The package advertises helpers for common query patterns including pagination, plus consistent error handling and debugging aids. These are convenience wrappers rather than a spec-compliant pagination implementation, so confirm the connection shape matches Relay-style cursor expectations if your clients rely on them. Review the error handling code to ensure it does not leak internal exception details into GraphQL responses in production.
- How do I maintain a forked version of garlic/graphql-php-tools?
- Vendor the source into an internal namespace or a private Composer repository and treat it as first-party code you own. Add CI, static analysis, and contract tests that pin the merge semantics you depend on so future PHP or graphql-php upgrades fail loudly instead of silently changing type resolution. Budget a compatibility review each time your stack upgrades, since no upstream patches will arrive.