Laravel Turbomaker Laravel Package

Product Decisions This Supports

• Feature enablement: This package is the integration layer that lets Laravel applications drive ModelSchema generation through a single generateAll() entry point. It is the piece that turns schema definitions into generated models/artifacts, so it underpins any roadmap item involving scaffolding, starter kits, admin-panel bootstrapping, or internal developer-platform "generate from schema" workflows.
• Build vs. buy signal: The adapter pattern (thin package wrapping grazulex/laravel-modelschema generators) argues for buying/adopting rather than building a bespoke generation pipeline — the value is in the orchestration and Laravel ergonomics, not the generators themselves.
• Trust in generated output: v2.5.1 fixes a correctness defect where generateAll() returned simulated results instead of invoking the real GenerationService. Any product decision made on v2.5.0 or earlier — demos, internal tooling, generated code committed to repos — was based on fake output and should be re-validated before it informs further roadmap commitments.
• Use cases to prioritize: one-off project scaffolding, CI-driven regeneration of models when schema changes, multi-source schema aggregation (multiple generators feeding one call), and developer-experience tooling where developers supply schema fragments and expect either artifacts or an explicit failure.
• Failure semantics as a product contract: The new "fails when a generator returns no fragments" behavior is a product-level decision, not just a bug fix — it makes silent no-ops visible. This supports decisions to expose generation as a gated CI step rather than a best-effort convenience.

When to Consider This Package

Adopt when:

• You are on Laravel and already use, or are willing to adopt, grazulex/laravel-modelschema (^1.3.1 or later is now mandatory).
• You need to run multiple generators in one pass and want a single generateAll() surface rather than wiring each generator manually.
• You want generation failures to be loud — empty output from any generator is a hard error you can surface in CI or in your product's health checks.
• Your schema-to-model generation is a developer-facing or internal workflow where a thin abstraction over the underlying generators is sufficient.
• You are starting fresh on v2.5.1 or later; there is no migration debt from the simulated-results era.

Look elsewhere or defer when:

• You are pinned to grazulex/laravel-modelschema <1.3.1 — v2.5.1 will not install, and downgrading the adapter to get simulated results is the wrong trade.
• You need generation that is resilient to partial input, i.e. you want best-effort output rather than hard failure on empty fragments. The new contract is deliberately strict.
• You need provenance, audit trails, or deterministic reproducibility guarantees for generated artifacts — this release makes generation real, but does not add observability around it.
• You are not on Laravel, or you have a single generator where the adapter adds indirection without benefit.
• You were relying on v2.5.0's simulated output for demos or fixtures. Do not upgrade blindly; re-baseline instead.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel integration package that standardizes how our applications turn schema definitions into generated code. The v2.5.1 release is a correctness release, not a feature release: prior versions of generateAll() returned placeholder results instead of doing real generation, which means any prototyping or internal tooling built on it should be treated as unvalidated until re-run. The fix makes generation genuinely functional and makes silent failures impossible. Net effect: the package is now viable for developer-workflow use cases, and we should only commit to roadmap items built on it after re-running generation on v2.5.1 and confirming output quality.

For engineering: Upgrade to v2.5.1 and bump grazulex/laravel-modelschema to ^1.3.1 as a single change — they are coupled. Expect behavior changes despite the patch version: generateAll() now invokes the real GenerationService, and it throws when any generator yields no fragments. Audit any code path or test suite that asserted on the old simulated output; those assertions will now fail, correctly. Add a smoke test that generates from a known-good schema and asserts non-empty artifacts, and treat generation as a CI gate rather than a developer convenience. Watch for generators that legitimately produce zero fragments for valid inputs — those will now be hard errors and may need schema or generator-side fixes rather than adapter-side workarounds.