Kit Generator Bundle Laravel Package

Getting Started

Read this first: this is not a Laravel package. Despite the "PHP toolkit" phrasing in the description, kitlabs/kit-generator-bundle is a Symfony bundle that extends SensioGeneratorBundle — the Symfony 2.x/3.x code-generation bundle that was superseded by MakerBundle in Symfony 4. It has no service provider, no extra.laravel block in composer.json, no config publish tag, no facade, and no Artisan commands. On a Laravel stack there is no supported path to wire it in: composer require will pull Symfony 2/3-era constraints that conflict with the symfony/* versions Laravel itself depends on, and even under forced resolution nothing registers the bundle's console commands into php artisan.

So the "getting started" story splits in two:

1. If your target is Laravel — the minimal steps are: don't install it. Use php artisan make:*, published stubs, Laravel Blueprint, or Filament generators. There is no adapter, fork, or shim, and the Doctrine/Symfony assumptions of the emitted artifacts (bundles, annotated entities) won't map to Eloquent models or migrations without hand-editing everything.
2. If you actually maintain a Symfony 2.7–3.4 app that already depends on SensioGeneratorBundle — that is the only context where this package is coherent. Minimal steps:
   • composer require --dev kitlabs/kit-generator-bundle (dev-only; this is scaffolding tooling).
   • Register the bundle in app/AppKernel.php inside the dev/test branch of registerBundles().
   • Confirm the bundle's generator commands appear in php bin/console list generate — if they don't, the bundle isn't loading (see Gotchas).
   • Inspect vendor/kitlabs/kit-generator-bundle/ for the commands it registers and what kits it ships. Do this before trusting it — the description is one line, the star count is 5, and there are 0 dependents, so the source is the documentation.

First real use case (Symfony, legacy only): generating a CRUD scaffold for a Doctrine entity — the standard generate:doctrine:crud-style flow, with this bundle layering kit-specific templates (bundle skeleton, controllers, config, assets) on top of the stock generators. The value proposition is "template once, generate consistently," which is exactly the same value artisan make:* + stubs delivers in Laravel without importing a dead framework's tooling.

Implementation Patterns

Patterns here assume the legacy-Symfony context, since that's the only one where the package executes at all.

Kit-as-template workflow. The intended day-to-day loop mirrors Symfony's generator lifecycle: you define a reusable kit (a bundle-shaped directory of stubs — controllers, config YAML, Doctrine entity skeletons, assets), then invoke a generator command that copies and substitutes placeholders into the host application. The "kit" is the unit of reuse; a team standardizes a kit and everyone generates from it, so new modules arrive with consistent structure instead of each developer hand-rolling.

Composition over monolithic scaffolds. Kits are meant to be composable — a base kit plus feature kits (e.g. crud-kit + admin-kit + api-kit) rather than one giant generator. In practice this means your kit definitions live under version control alongside the application, and kit updates propagate through regeneration rather than manual edits.

Dev-time-only integration. Register the bundle in the dev kernel branch only, and treat any generated code as a starting point for review — never as a build artifact. The generated files enter the repo like any other code, get reviewed like any other code, and are then hand-maintained. This is the same posture as artisan make:* output.

Integration point that does NOT exist for Laravel. There is no Laravel analogue of bundle registration — no ServiceProvider, no Artisan::command discovery, no php artisan vendor:publish. If you want the pattern (declarative kit definitions → generated modules) in Laravel, the closest maintained equivalents are:

• Artisan make:* with published stubs (php artisan stub:publish) for one-file-per-command generation.
• Blueprint (php artisan blueprint:build) for declarative, YAML-driven multi-file generation — this is the actual functional equivalent of "template-driven kit generation" in the Laravel ecosystem.
• Filament / Backpack generators for admin-CRUD scaffolds.

If a Symfony team is genuinely requesting this, the correct answer is MakerBundle, not a third-party extension of the deprecated bundle — MakerBundle is where the ecosystem's maintenance, docs, and security attention currently live.

Gotchas and Tips

• Installation will likely fail before anything else. Composer resolution against a Laravel 9/10/11 app will conflict on symfony/* versions. If someone forces resolution, the result is a downgraded shared dependency tree with nothing wired into the app — dead weight retained for zero benefit. Record the resolution failure verbatim if you need evidence to close the evaluation.
• Silent non-registration is the most likely "it installed" failure. Symfony bundles only register via AppKernel (or, in modern Symfony, config/bundles.php). There is no autodiscovery equivalent to Laravel's package discovery, so a successful composer require means nothing — check php bin/console list generate explicitly.
• SensioGeneratorBundle is EOL. Even in a Symfony context, this package is a layer on top of a bundle you shouldn't be starting from. If it appears in a dependency audit, treat that as a framework-upgrade signal, not a package to invest in.
• Zero downstream validation. 5 stars, 0 dependents, no release cadence, no CI, no security policy. Nobody has tested this against a current framework. Every incompatibility is yours to patch, and there's no upstream to fix it.
• Artifact drift. Generated output follows Symfony conventions — bundles, Doctrine annotations, YAML config. In a mixed or modernizing codebase this diverges from current conventions and becomes a review liability rather than a time-saver. Dev-time generators are low security risk but high organizational risk: non-idiomatic output spreads across every team that adopts the tool.
• Extension points are not documented. The only reliable way to learn what this package adds beyond stock generators is to read vendor/kitlabs/kit-generator-bundle/ directly — command classes, service definitions, and template directories. Budget for that before assuming it does something upstream doesn't.
• The supply-chain angle is worth stating plainly. An abandoned, dev-only package still executes in developers' terminals and CI runners with repository access. Low blast radius ≠ no blast radius. Low-star, zero-dependent packages are a known soft spot.
• If a spike is demanded anyway: timebox it to a day in a throwaway branch. Steps — confirm the actual framework-of-record, attempt composer require, inspect the bundle's command registrations, document the rewrite surface, then compare against writing 2–3 custom Artisan commands with stubs (typically 1–2 days) or adopting Blueprint. The comparison almost always closes the discussion in favor of the Laravel-native route.