Laravel Api Scaffold Laravel Package

Product Decisions This Supports

• Build vs. buy for CRUD/API boilerplate: v0.4.0 pushes the package past "table → controller" scaffolding into model-layer generation. If your roadmap includes a large surface of CRUD endpoints over a relational schema (admin panels, internal tools, partner APIs, back-office ingestion), this is a credible reason to standardize on a generator rather than hand-write or buy a heavier platform.
• Time-to-first-endpoint as a roadmap lever: Foreign-key introspection now produces belongsTo / hasMany on both sides of a relationship, so generated APIs are usable for nested resources out of the box. This shortens the "schema exists → demoable API" interval, which is typically the expensive part of an early milestone.
• Scope decisions on schema shape: The package only derives belongsTo / hasMany from real foreign keys and explicitly does not generate belongsToMany or polymorphic relations. That's a useful forcing function in design reviews — if a domain needs many-to-many, you know it's hand-written work, not generated work, and can plan capacity accordingly.
• Data-model contracts and tooling: Generated model PHPDoc (column types, nullability, Carbon for timestamps, Collection<int, Model> for inverse relations) gives IDE/static-analysis coverage for free. That affects decisions about adopting PHPStan/Larastan or IDE helper tooling — this partially replaces them for generated models.
• Cross-database standardization: MySQL/MariaDB and PostgreSQL are both validated for FK introspection. This supports decisions to keep a single scaffolding tool across heterogeneous environments (e.g., MySQL in dev/legacy, PostgreSQL in production).
• Type-safety position on money: Decimals documented as string (matching Laravel's decimal:2 cast) rather than float is the correct default for currency and financial amounts. This is a policy decision the PM can endorse rather than debate: no floating-point money in generated models unless a team explicitly opts in.
• Regeneration as an operating model: Because --force regeneration is the workflow, adopting this package implies a decision that generated models are not the place for hand-written business logic. That has downstream consequences for where custom code lives (services, actions, or a separate layer) and should be settled before rollout, not after.

When to Consider This Package

Adopt when most of these hold:

• You have a stable or moderately stable relational schema with genuine foreign keys. The relationship generation is only as good as your constraints — schemas that enforce integrity in application code rather than in the database will produce models with missing relations.
• You are standing up many similar CRUD resources and the per-resource effort of writing models, casts, PHPDoc, controllers, routes, and feature tests is the bottleneck.
• Your domain is predominantly one-to-many. Hierarchies like customer → transactions, order → line items, tenant → records map cleanly onto the generated belongsTo / hasMany output.
• You want generated feature tests as a starting baseline — v0.4.0 reports passing generated API tests on both MySQL and PostgreSQL consumers. Treat these as a smoke-test floor, not a substitute for domain tests.
• You are on MySQL/MariaDB or PostgreSQL and willing to run the regenerate workflow (scaffold:model / scaffold:api with --force) after schema changes.
• You accept v0.4.x maturity: pre-1.0 versioning, generated output shape still changing between minor releases, and Octane/Swoole users needing a documented reload step.

Look elsewhere or defer when:

• Many-to-many or polymorphic relations are central. Explicitly out of scope in this release; you would be hand-maintaining the most interesting parts of the model layer anyway.
• Generated models must be the home of business logic. --force regeneration conflicts with hand-edited models; if the team won't adopt a service/action layer, this becomes a footgun.
• Schema is volatile and unconstrained. Frequent migrations plus missing FK constraints degrades relationship quality and turns regeneration into churn.
• The schema is non-relational or FK-poor (document stores, event-sourced, heavy JSON), where the new introspection adds little.
• You need a guarantee of API stability. Pre-1.0 means generated model output can change in a minor version — the v0.4.0 notes themselves say output changed. Pin versions and diff regenerated files in review.

How to Pitch It (Stakeholders)

For executives: This release moves our scaffolding tool from generating endpoints to generating the data layer. It now reads foreign keys in the database and writes the corresponding Eloquent relationships in both directions, plus structured type documentation on every generated model. Practically: the CRUD-and-relationships work that currently takes an engineer a day or more per resource becomes a command. It works on both MySQL and PostgreSQL, verified against real consumer projects with passing tests. It's a pre-1.0 package — we pin the version, review regenerated diffs, and keep hand-written logic out of generated files — but the direction is a meaningful reduction in boilerplate cost across our API surface.

For engineering: v0.4.0 adds FK introspection for MySQL/MariaDB and PostgreSQL, emitting belongsTo on child models and inverse hasMany on parent models, with imports added only when used. Models now carry PHPDoc for columns and relationships, including Collection<int, Model> for inverse relations and string for decimals to match decimal:2 casting. Behavior is gated by a new models config block (generate_relationships, generate_phpdoc, phpdoc_decimal_type), so we can adopt incrementally. Package suite is at 58 tests / 274 assertions, with end-to-end validation on both drivers. Two operational notes: regenerating requires --force and will overwrite models, so custom logic belongs in a service layer; and Octane/Swoole deployments need optimize:clear + octane:reload after config publish or regeneration. Upgrade is composer require caminodeldev/laravel-api-scaffold:^0.4.0 -W, then refresh published config and clear caches. Not included: belongsToMany and polymorphic relations — those remain manual.