liinkiing/graphql-maker-bundle
A Symfony bundle that adds Maker commands for scaffolding GraphQL types, queries, and mutations, helping you generate GraphQL APIs from your entities with less boilerplate and consistent, framework-friendly code.
This is a scaffolding tool, not a runtime library. It does nothing at request time — it adds MakerBundle-style console commands that write PHP classes in the shape Overblog GraphQLBundle expects. Judge it on how much typing it saves you during a schema-building sprint, not on production behaviour.
If you are on a Laravel codebase, the honest starting position is: this bundle does not apply to you. It is a Symfony bundle that hooks into Symfony's kernel/bundle registration, DI container, and Overblog GraphQLBundle's type conventions. There is no service-provider shim, no artisan command, no Laravel-native integration. For Laravel, look at Lighthouse or webonyx/graphql-php (with custom artisan generators if you want scaffolding) instead. Everything below is written from the perspective of a Laravel developer evaluating the tool — either for a Symfony service in your estate or to harvest ideas for your own generator.
Prerequisites before you install anything (Symfony context):
overblog/graphql-bundle already installed and configured (config/packages/overblog_graphql.yaml exists, a /graphql endpoint responds).symfony/maker-bundle present as a dev dependency — this bundle builds on its AbstractMaker/MakerInterface plumbing.App\GraphQL\Type, App\GraphQL\Input, …), because the generators bake namespace decisions into every file they emit.Minimal steps:
composer require --dev liinkiing/graphql-maker-bundle
# register in config/bundles.php only if Flex doesn't do it for you
bin/console list make:graphql
That last command is your real documentation. The README is thin and the repo has ~10 stars and no known dependents, so treat bin/console list make:graphql and the bundle's Maker/ directory on GitHub as the source of truth for what commands and options actually exist in the version you installed. Options drift between releases; don't trust blog posts.
First use case, and the one that tells you whether this package is worth keeping:
bin/console make:graphql:type Foo — confirm the exact name from list).bin/console overblog:graphql:dump-schema, or the equivalent in your Overblog version) and confirm the type appears.If steps 3–5 feel smoother than writing the YAML/PHP by hand, keep going. If the generated file needs rewriting anyway, stop here — the tool has already told you what it's worth.
Also check early whether the bundle exposes a config tree (look for DependencyInjection/Configuration.php in the repo or bin/console config:dump-reference <bundle_alias>). Output directory and base namespace are usually configurable; getting them right up front saves a rename sweep later.
Scaffold-then-edit, never scaffold-and-ship. The generator knows nothing about your Doctrine relations, enums, access control, or nullability requirements. Treat its output as a first draft with the right shape and namespace, then finish it by hand and review it like any other source. If you commit raw generator output without a human pass, you will ship resolvers that leak fields your authorization layer thought were hidden.
Batch your scaffolding sessions. The productivity win compounds when you generate several related types in one sitting — an entity type, its input type, the query that returns it, and the mutation that creates it — because the generator reuses your namespace conventions within a run. Generating one type one day and another the next is closer to hand-writing cost and not worth the mental context switch.
Drive from Doctrine entities where the mapping is obvious. The bundle advertises "Doctrine entity-driven workflows"; use that as your entry point for types that mirror a table 1:1 (id, timestamps, simple scalar columns). For anything that crosses entities, aggregates, or has computed fields, scaffold against a plain class and fill in the shape yourself — the entity driver will happily emit a type that exposes your $password column if you're not careful.
Keep a hand-written reference type in the repo. Maintain one "golden" object type that reflects your team's actual conventions — field naming, nullable patterns, resolver class placement, documentation strings. Every time you scaffold, diff the generator's output against it before accepting. This is the cheapest way to catch generator drift after an upgrade and it doubles as the onboarding artifact for new backend engineers.
Wire types explicitly into Overblog's config. Scaffolding writes the PHP file; it does not silently register the type with the schema. You still need to add it to overblog_graphql.yaml (or wherever your type definitions live). Budget for that step every time, and consider a tiny custom Symfony command or a CI check that asserts every class under your GraphQL namespace appears in the type config — otherwise dead types accumulate silently.
Prefer the generator for repetitive shapes, not for the interesting ones. Use it for the boring 80%: entity-backed object types, paginated list queries, simple CRUD mutations. Write the unions, interfaces, custom scalars, subscriptions, and anything with resolver logic by hand. Mixing the two approaches is fine and normal; the generator is a tool for the middle of the spectrum, not the edges.
Version-pin and vendor if you adopt. This is require-dev only, but no dependents and a ~10-star profile means the upstream may not track your next Symfony or Overblog major. Pin an exact version ("liinkiing/graphql-maker-bundle": "1.0.0", no caret) the moment you decide to keep it, and consider committing the bundle source to a patches/ or internal repo so a framework upgrade can't be blocked by an abandoned dependency.
If you are on Laravel and inspired rather than adopting: the pattern worth transplanting is a single artisan command (php artisan make:graphql-type Foo) that resolves a target namespace, reads a stub file, and writes a typed stub with the right use statements. That's roughly 150 lines of code and avoids taking a Symfony bundle as a dev dependency in a stack that can't run it.
Framework mismatch is the number one gotcha. Every assessment of this package leads with it for a reason: the description says "PHP" but the implementation is Symfony-kernel-coupled. Installing it in Laravel will either fail on Composer constraints or install and do nothing. If a stakeholder forwards you this package as a "Laravel GraphQL codegen" candidate, close the ticket with a link to Lighthouse or webonyx/graphql-php.
bin/console list is the README. Command names, arguments, and options shift between this bundle's versions and differ from the docs you find in blog posts. Always discover what you actually installed rather than typing the command from memory; a silent rename from make:graphql:type to make:graphql:object is a confusing fifteen minutes.
Watch for command-name collisions with MakerBundle and other makers. Both bundles live under the make: namespace. If a third-party generator (e.g. a doctrine-maker extension) also claims a namespace segment, you can get nondeterministic command resolution. Confirm the full command path from list before assuming your invocation hit the right class.
Scaffolding will not register your type. Generated files are just files. They must be added to Overblog's types config (usually an explicit list or a glob in overblog_graphql.yaml). Forget this and you'll spend a debugging session staring at a schema dump that stubbornly refuses to include your new type — the error is not in the generated code, it's in the wiring.
Generated code drifts after every upgrade. Because no dependents exist, there is no compatibility net. Before bumping Symfony, Overblog, or PHP majors, generate a throwaway type against the new version and diff against your golden reference. If it changed shape, either accept the change consciously across the codebase or pin the bundle. This is the routine maintenance cost of the fork-and-own posture the tool demands.
Doctrine entity discovery is convention-bound, not magic. The entity-driven flow will look in the configured entity directory with configured namespaces. If your entities live under a nonstandard namespace, or you use read-model DTOs rather than Doctrine annotations/attributes, the generator will quietly not find them and you'll fall back to hand-typing — usually worth doing anyway, but note it so you don't burn time chasing the "why is my entity invisible" question.
Config quirks around namespace and output path. The bundle's config typically exposes a base namespace and output directory; if you leave defaults and your project uses nonstandard layouts, you get files written to src/GraphQL/Type/ while your real code lives elsewhere. Set these in config/packages/ before generating anything — a subsequent rename sweep across fifty generated files is a bad time.
There is no meaningful extension-point story beyond stubs. MakerBundle allows custom stubs and template overrides; this bundle inherits some of that machinery but only lightly. If your conventions differ from what it generates (e.g. you want constructor-injected resolvers or PHP 8 attributes rather than annotations), the cleanest path is usually fork the stub files, not patch the generator. Keep the fork small and vendored so a Symfony upgrade can't take the fork with it.
Debugging generated types is normal GraphQL debugging. When a scaffolded type doesn't appear in the schema, check in this order: (1) the file was written where overblog_graphql.yaml looks; (2) the class is registered in the type config; (3) the class namespace matches what Overblog's type_loader resolves; (4) bin/console overblog:graphql:dump-schema reflects it; (5) cache cleared (bin/console cache:clear — Overblog caches the schema, so a stale type list is a common red herring).
Do not put this on a critical build path. No runtime failures here, but also no maintenance guarantees. If you wire it into CI to regenerate types automatically on deploy, an upstream break silently corrupts your schema. Keep it as a local developer convenience; regenerate and commit by hand, review the diff, ship normal source.
How can I help you explore Laravel packages today?