Code Generator Laravel Package

Product Decisions This Supports

• Build vs. buy for schema-to-code scaffolding. krlove/code-generator is the engine layer for generating PHP classes (models, DTOs, repositories) directly from an existing database schema, with per-table class mapping, naming strategies, type mapping, and customizable templates. The decision it informs is not "should we write a code generator" but "should we write one from scratch, fork this, or buy an admin/CRUD platform."
• Legacy database reverse-engineering roadmap. If a roadmap item is "modernize the monolith" or "wrap the existing MySQL schema in Laravel," this is the cheapest way to get from 80 tables to 80 typed classes in an afternoon. That directly sets the timeline estimate for migration epics.
• Developer onboarding and time-to-first-PR. Generated model/DTO layers remove the most tedious, error-prone part of onboarding onto an unfamiliar schema. This is a measurable PM lever (onboarding cost per engineer) rather than a purely technical choice.
• Standardization and code-review load. Template-driven generation enforces one shape for generated classes, which reduces review variance and style debates. This supports a decision to standardize scaffolding across teams instead of letting each squad hand-roll.
• Scope-of-investment decision on internal tooling. With 68 stars, no release since Feb 2022, and an archived repository, the artifact itself is not a vendor bet — it is a reference implementation. The PM decision it supports is whether to allocate a small internal-tooling budget (fork + pin + own it) versus deprioritize scaffolding entirely.
• Opportunity signal, not adoption signal. The high opportunity score (0.81) against a 0.735 overall score reads as "the problem space is valuable; this specific artifact is stale." That is a cue to evaluate the category (schema-driven generation) separately from this package.

When to Consider This Package

Adopt or borrow it when:

• You have a pre-existing, non-trivial database schema and need Laravel/Eloquent-style classes fast; hand-writing them is pure cost.
• You want repeatable, CI-runnable generation (regenerate after schema changes) rather than a one-shot copy-paste from a GUI tool.
• Your team is comfortable vendoring or forking a small library and owning it — the code path is dev-time only, so the blast radius is bounded.
• You need template customization (field naming, type maps, relation inference, per-table overrides) rather than a rigid one-size-fits-all generator.
• You are generating DTOs/value objects/repositories from schema as a deliberate architectural choice, not just Eloquent models.

Look elsewhere when:

• You need an actively maintained dependency with a support contract. It is archived; assume no security patches, no PHP 8.3+/Laravel 11+ guarantees without verification, and no upstream bug fixes.
• You want runtime or production behavior. This is a development-time codegen utility — if your requirement is dynamic schema introspection at request time, that's a different (and heavier) design.
• You want an admin panel or CRUD UI. Filament, Nova, or a Laravel CRUD-generator suite covers screens, auth, and validation — this package stops at class generation.
• You are Doctrine-centric; use Doctrine's own tooling so mapping conventions stay consistent.
• You need multi-language or non-PHP output, or generation driven by an API spec rather than a database (OpenAPI generators are the right category there).
• Your schema is small or greenfield — migration-first authoring is cheaper than reverse-engineering, and generated code becomes throwaway.

How to Pitch It (Stakeholders)

For executives: This is a small, free, development-time utility that turns an existing database into typed PHP classes automatically. It is not something we ship to customers, so it carries no runtime or security exposure in production. It is useful as a starting point and pattern, not as a dependency we adopt on faith: the project is archived and unmaintained, so the realistic proposal is "fork it, pin it, and own roughly 1–2 engineer-days of work," not "add it to the stack." Expected payoff is faster legacy-schema migration and cheaper onboarding; the cost of being wrong is low and reversible.

For engineering: Treat it as a reference implementation for schema-driven codegen. Vendor or fork, add it as a dev-only dependency behind a console command, generate into a clearly marked output namespace, and keep generated code out of hand-edited paths (or use a "generate once, then own it" convention). Validate against our actual PHP/Laravel versions before committing — no releases since Feb 2022 means compatibility is an assumption, not a guarantee. Do not put it on a critical path without a named owner. If the templates fight us, the fallback is a few hundred lines of our own generator using the same idea.