Generator Bundle Laravel Package

Product Decisions This Supports

• Closing out a build-vs-borrow evaluation for developer scaffolding. The decision space here is "should we invest in code generation for boilerplate?" — the same space as Laravel's native artisan make:*, publishable stubs, or an internal skeleton package. This artifact is a worked example to evaluate and reject, not a candidate to adopt.
• Framework-fit triage on inbound package requests. Despite being filed as a Laravel/PHP package, this is a Symfony bundle. It cannot register a service provider, will not participate in Laravel package discovery, and assumes AppKernel/config/bundles.php wiring. For a Laravel roadmap the evaluation ends here — the correct product action is to record the mismatch and route the requester to Artisan.
• Dependency-governance policy inputs. Archived repo, 2 stars, 0 dependents, MIT license, overall score ~0.29. Use it as the canonical negative example when writing the bar for third-party adoption: maintenance status, supported framework versions, security response path, and downstream validation.
• Onboarding-velocity baseline. The value proposition — removing repetitive class creation (models, controllers, migrations, form requests, test stubs) — maps to "time to first working feature" and new-engineer ramp-up KPIs. Worth measuring as a baseline regardless of which generator tooling we standardize on, so any future internal build has a before/after number.
• Reference design for a first-party generator (not a dependency). If engineering wants house-style scaffolding — company naming conventions, DDD folder layout, standard audit columns, test stubs — the bundle's Twig skeleton structure and field-derivation logic are cheap prior art for a 1–2 sprint internal build. Harvest ideas; do not adopt code.

When to Consider This Package

Consider it only as read-only reference material, and only if:

• You want a half-day spike to inventory the generator commands and Twig stub templates before deciding whether internal scaffolding is worth building.
• You are on a legacy Symfony 2.7–3.x application with a hard need for its specific skeleton output — and even then, Symfony MakerBundle is the maintained, first-party answer.
• You intend to fork it (MIT permits this) and own it outright as a starting codebase. Budget a named maintainer; never add it to composer.json as a live dependency.

Look elsewhere — strongly — when:

• The project is Laravel. Wrong framework entirely. Laravel already ships make:* Artisan generators and php artisan stub:publish; there is no overlap to exploit.
• You need maintained software. Archived means no PHP 8.x fixes, no Symfony 6/7 work, no CVE triage, no issue response — and with 0 dependents there is no community to absorb that cost. We would be sole maintainer on day one.
• You need confidence. 2 stars and 0 dependents is effectively zero production validation: nobody to ask when it breaks, no ecosystem pressure keeping it correct.
• A first-party alternative exists. Symfony MakerBundle covers the same ground with core-team maintenance; on Laravel, Artisan plus a stub set does the same. This package is redundant on the merits alone.

Recommendation: do not adopt. The decision this supports is explicitly negative — a useful data point for dependency policy and a reminder that "generator bundle" search results can be years stale. Direct engineering to native tooling or an internal stub package.

How to Pitch It (Stakeholders)

One line: A small MIT-licensed Symfony boilerplate generator that is archived, unmaintained, and has no downstream users — it does not belong in our dependency tree, and it is not even a Laravel package.

For executives: This is not a build/buy call, it is risk avoidance. Pulling in archived software means we become the sole maintainer of code we did not write, for a benefit that maintained first-party tooling already delivers for free. Cost to skip: zero. Cost to own: an unnamed, unbudgeted internal fork that will quietly break on every framework upgrade. The scoring tells the same story — a low overall score against essentially no adoption signal.

For engineering: The category is right — scaffolding cuts repetitive class creation and speeds onboarding — but the artifact is wrong. It is Symfony-only, archived, and backed by 2 stars / 0 dependents, meaning no real-world validation and no upstream to patch. Use Laravel's make:* Artisan generators plus published stubs for standard scaffolding; if we want company-specific conventions (naming, DDD structure, audit fields, test scaffolding), spend a sprint building an internal package modeled on this bundle's template layout. Artisan and this bundle both sit on the Symfony Console component, so the command ergonomics are transplantable even though the bundle wiring is not — but the port is only justified if the spike finds genuinely reusable stub IP, and it needs a named owner and a maintenance budget, not a composer require.