Maker Bundle Laravel Package

Product Decisions This Supports

• Time-to-first-working-code as a roadmap metric. MakerBundle is the shortest path from "empty Symfony app" to a running controller, command, entity, form, voter, message handler, or security flow. It supports decisions about whether to invest in onboarding tooling at all — a one-line composer require --dev and make:* gets a new hire to a reviewable PR on day one rather than a day three.

• Convention enforcement at the point of creation. Generated code reflects the maintainers' current recommended defaults, and defaults have historically evolved (e.g. make:form output suffix, invokable commands by default, attribute-based Twig extensions, generate_final_entities config). Adopting it is a decision to let upstream Symfony define your house style for boilerplate, and to spend your own standards budget on domain code instead. If you have an opinionated internal style guide that diverges, that is a real trade-off to name up front.

• Build vs. buy for internal scaffolding. The project explicitly declares broad extensibility, pluggable generators, custom templates, and alternative target directories out of scope, and points to coding agents with dedicated skills (Symfony Mate) or other codegen tools instead. That is a clean line: buy the 80% standard skeleton; don't build a generator platform on top of this. If a PM is scoping an "internal project template" initiative, this repo's scope statement is the strongest available argument for either (a) adopting and stopping, or (b) going to an agent-based generator instead of forking.

• CI and automation viability. Non-interactive support is now a first-class, documented quality bar: the bundled AGENTS.md states every maker must work under --no-interaction, and v1.68 shipped a swath of --no-interaction crash fixes plus new --field / --relation / --controller-class options for scripted use. This supports decisions to use make:* in project bootstrap scripts, container image builds, smoke tests, and agent-driven workflows — but with the caveat below.

• Support-matrix and upgrade planning. v1.68.0 raised the floor to Symfony 7.4+ and PHP 8.2+, and the README states only the latest Symfony LTS is supported, with generated code targeting that LTS. Every LTS transition therefore becomes a scheduled decision point: bump the bundle and re-baseline generated code, or freeze. Useful as a forcing function in roadmap planning.

• Risk classification for a dev-dependency. It is MIT, dev-only, and maintained within the Symfony organization with a steady release cadence through 2026. It should not appear on a production runtime risk register; it belongs on a developer-experience and toolchain-churn watchlist.

When to Consider This Package

Adopt when:

• You are building or maintaining a Symfony application (this is not a Laravel package; there is no overlap with Laravel's make:* artisan generators) on the current LTS.
• Your team includes people learning Symfony, or experienced engineers picking up an unfamiliar component — the stated audience is exactly "wants a working starting point without writing boilerplate."
• You want generated code to track upstream best practices automatically rather than maintaining your own skeleton files.
• You need a reference implementation to diff against during a major upgrade: generate the same artifact on the new version and compare shapes.
• You are standardizing or auditing non-interactive scaffolding for CI or AI-agent workflows — the AGENTS.md guidance (values on the InputInterface not on properties, RuntimeCommandException for machine-readable errors, VALUE_NONE for booleans, guarding double composer require) is unusually explicit documentation of the failure modes worth reviewing in any generator you rely on.

Look elsewhere, or scope down, when:

• You need scripted stability. The BC promise is explicitly weakened: command arguments/options may change between minor releases, and generated code itself changes between minors. If your pipeline shells out to make:* and asserts on output, pin the version and treat upgrades as a tested change, or keep generated code out of automated gates.
• You need customization. Custom templates, alternate directories, opinionated code shapes, and pluggable generators are declined by design — not backlog gaps. Requests there will not land. Use coding agents with dedicated skills, Symfony Mate, or your own tooling.
• You are not on the latest LTS. Older Symfony versions are out of support; expect generated code and dependencies to mismatch.
• You are building a generator product, not an app. This is a developer convenience, not an extensible codegen framework.
• A Flex recipe already covers it. Makers whose output is fully recipe-covered are deliberately excluded, so don't plan for coverage that the maintainers have ruled out of scope.

How to Pitch It (Stakeholders)

For executives (one paragraph): MakerBundle is a free, MIT-licensed, dev-only Symfony tool that turns "write the boilerplate for a controller, entity, command, or login flow" into a single command producing code that matches current Symfony best practice. It is maintained inside the Symfony organization, ships regularly, and adds no production runtime dependency or licensing cost. The business case is developer throughput and consistency: faster ramp-up for new hires, less hand-written boilerplate to review, and a standard starting shape across the team. The main caveat is that it deliberately does not support custom templates or pluggable generators, so it is a "use as-is and stop" tool rather than a platform to build on — which is also why it carries almost no strategic or vendor risk.

For engineering leads (short brief): Add it as a require-dev dependency and use make:* for standard artifacts; treat generated output as a starting point to be reviewed and edited, not as a locked contract. Two operational facts to design around: (1) command inputs/options and the generated code may both change in minor releases, so pin the version and upgrade deliberately alongside Symfony LTS bumps — v1.68.0 already moved the floor to Symfony 7.4 / PHP 8.2; (2) non-interactive mode is now an explicit support guarantee, with --field, --relation, and --controller-class options intended for scripting, so make:* --no-interaction is reasonable in bootstrap and agent workflows — but validate stdout/exit codes rather than parsing generated files. Do not invest in forking or extending the generators; the maintainers have written extensibility out of scope and point to agent-based skills tooling for anything beyond the defaults. Budget roughly one small upgrade task per Symfony minor release to re-baseline expectations.