- Can I use liinkiing/graphql-maker-bundle in a Laravel application?
- No. This is a Symfony bundle built on Symfony's kernel and DI container, MakerBundle's AbstractMaker plumbing, and Overblog GraphQLBundle's type-definition conventions, none of which map onto Laravel's service-provider model. For Laravel, use Lighthouse, GraphQLite, API Platform, or direct webonyx/graphql-php instead.
- How do I install graphql-maker-bundle in a Symfony project?
- Install it as a dev dependency with Composer and register the bundle in your development bundles configuration. It is not standalone: it requires symfony/maker-bundle and overblog/graphql-bundle to already be present, so those adoption decisions come first. Because the project has very few stars and dependents, pin an exact version rather than relying on a wide constraint.
- Which Symfony, PHP and Overblog versions are compatible?
- Treat this as unproven until you check the repository's commit history and composer.json constraints against your stack. The project has negligible community activity, so assume the compatibility matrix may lag current PHP 8.x, Symfony 6/7 and the matching Overblog major. Price in a small fork or patch if you adopt it.
- What commands does the bundle add for creating GraphQL types?
- It adds Maker commands that scaffold GraphQL types, queries and mutations in the shape Overblog expects, reducing boilerplate when generating an API from your entities. Everything it produces is ordinary PHP source you commit and review like any other code. It has no request-time footprint and does not execute your schema.
- How do I configure namespaces and output paths for generated types?
- Check whether the bundle exposes a configuration tree (DependencyInjection/Configuration.php and config:dump-reference) so you can set namespace and output paths before generating anything. The generator bakes those choices into every emitted file, so a wrong early decision means a rename sweep across your schema. Also confirm the command names do not collide with your existing Maker bundle commands.
- Does it generate PHP 8 attributes or legacy annotations?
- Verify this in the repository itself before adopting, because the Maker templates decide the output format and the answer is not guaranteed for current PHP and Symfony majors. Inspect the templates and recent commits, then diff a generated file against your coding standards. If the templates emit annotations you no longer use, budget time for template edits or a fork.
- Is graphql-maker-bundle safe to use in production?
- Production risk is low because it is a dev-only scaffolding tool: generated PHP classes are committed as source and reviewed like any other code, and a defective generator produces bad diffs rather than outages. Dependency and lifecycle risk is high, given a single maintainer, no evident security-response process and a tiny user base. The realistic operating model is that you own this source once you adopt it.
- How does it compare with GraphQLite, API Platform or Lighthouse?
- It is not really a competitor to those: it is a thin scaffolding layer on top of Overblog GraphQLBundle for Symfony projects that have already standardised on Overblog. GraphQLite and API Platform are alternative GraphQL layers for Symfony, and Lighthouse is the Laravel equivalent. If your target framework is Laravel, this package does not apply at all.
- Is liinkiing/graphql-maker-bundle actively maintained?
- With roughly ten stars, zero dependents and a single maintainer, you should assume very little ongoing maintenance and plan accordingly. Check the last commit and release dates before committing, and decide up front who owns a fork if upstream goes quiet. The exit cost is low because rollback is simply removing a dev dependency.
- How do I evaluate it quickly before adopting?
- Run a one-to-two-day spike in a throwaway Symfony app using Overblog: generate three to five types mirroring a real slice of your schema, wire one into the type definitions configuration, and dump the schema to confirm it appears. Diff the generated output against your coding standards to see how much rewriting is needed. If type volume is only a handful, the generator may not pay for itself; it makes more sense at dozens of types.