Crudmaker Laravel Package

Getting Started

CrudMaker is a scaffolding generator, not a runtime dependency: it reads a YAML definition of your tables and emits migrations, models, controllers, routes, requests, and Blade views. Treat the install as a throwaway step in a clean context, not something you add to a production composer.json.

Minimal path:

# In a scratch Laravel app matching the version the package supports
composer require yab/crudmaker --dev
php artisan vendor:publish   # config + stubs/views

Then define one table in the published YAML (typically config/crudmaker.yml or a project-root crudmaker.yml — confirm against the README, since the config path moved between releases) and run the generator. The workflow centers on two commands: one to add a table definition (crudmaker:new) and one to build everything from the definitions (crudmaker:build). Verify the exact names and options with php artisan list after install rather than trusting blog posts — the package is archived and its docs have drifted from newer Laravel releases.

Where to look first, in order:

1. config/crudmaker.yml — the schema you'll actually be editing all day.
2. The published stubs/ and view templates — this is where you bend the output toward your conventions.
3. One generated migration + model pair — read them before generating anything else; they tell you how column types and naming are inferred.

First use case: generate a single trivial table (tags or categories) with an id, a name, and timestamps. You are not shipping it; you are reading the four or five files it produces to learn the generator's opinions about naming, validation, and routing. Only after that should you point it at a table you care about.

Implementation Patterns

YAML as the source of truth, generated code as a snapshot. Keep the definition file in version control alongside the app. When a table changes, edit the YAML and regenerate — but regenerate into a clean branch so you can diff. Generated code is a one-shot snapshot with no re-generation safety, so the discipline that makes this package usable is: commit generated output as its own commit, then commit hand-edits separately. That way the next regeneration is a readable diff instead of a merge nightmare.

Generate wide, then hand-wire. The generator is good at breadth — ten admin tables in an afternoon — and weak at relationships, authorization, and anything domain-specific. The productive rhythm is: generate the full set of tables (including foreign-key columns), then spend your time hand-editing the belongsTo/hasMany methods, policies, and form validation that the YAML can't express. Bulk-generate first, refine second.

Point it at admin surfaces, not customer-facing ones. The bundled view styles (the package ships theme variants such as inspinia and material) are opinionated and dated. Generated CRUD screens are perfectly serviceable for internal back-office tooling and a poor fit for a product surface you'll design later. This is also the fastest way to get a working admin panel on a legacy or inherited codebase.

Customize the stubs once, benefit forever. If your project has a base controller, a form-request convention, a repository layer, or a specific layout, edit the published stubs before generating more than a couple of tables. Every subsequent generation inherits your conventions, which is the difference between "useful kickstart" and "code I have to rewrite ten times."

Bootstrap-and-eject. The strongest pattern for a package with 31 stars and an archived repo: use it to scaffold a greenfield admin section, delete the dev dependency, and never look back. You get the file volume without inheriting an unmaintained package in your dependency graph.

Integration tip: if your app's Laravel version blocks the install (likely), scaffold in a throwaway app on a compatible version and copy the generated files across. The output is plain Laravel — migrations, Eloquent models, resource controllers — so it ports cleanly even when the package itself won't install.

Gotchas and Tips

Archived is the headline. No security patches, no Laravel 11/12 support, and Composer constraints that will fight a modern app. Expect composer require to fail on platform requirements. Do not add this to a project you intend to maintain for years; the opportunity score here (4.91) reflects that the idea is valuable, not that this implementation is safe to depend on.

Regeneration overwrites, silently. There is no merge, no "only if unchanged" guard. Copy generated files somewhere before re-running the build on a table you've already edited, or you will lose work. This is the single most common way teams get burned.

YAML errors surface as confusing exceptions. Indentation, quoting, and column-type spelling are the usual culprits, and the failure often appears three steps into generation rather than at parse time. Generate one table at a time and read stderr verbosely; do not batch twenty tables on the first run.

Naming drives everything. Table names are plural snake_case and cascade into class names, route names, view paths, and variable names. A table named user_log_entries becomes UserLogEntryController, user-log-entries routes, and user_log_entries views. Get the table name right in the YAML before generating; renaming afterward means touching every generated file.

Column types need an audit. Enums, JSON, nullable timestamps, soft deletes, and foreign keys typically need manual correction in the migration and matching validation rules in the request. Read every generated migration before running migrate — especially check for collisions with migrations you already have.

Routes and middleware are the security gap. Generated routes usually land in web.php or a dedicated file with no auth middleware. Before anything reaches a shared environment, wrap the resource routes in your auth/can: middleware and confirm the generated controller doesn't find() without scoping. Generated CRUD is unauthenticated CRUD by default.

No tests are generated. Write feature tests for the generated endpoints yourself — list, create, update, delete, and one authorization-denied case. It's a small cost and it catches the middleware gap above.

Extension points worth knowing: published stubs (override output shape), published view templates (override UI), and the config file itself (default paths, namespaces, style). If you find yourself hand-editing the same thing in every generated controller, that's a signal to change the stub, not the output.

Debugging routine: scaffold into a clean app first when something looks wrong; diff a freshly generated file against your committed version to see exactly what the generator changed; and read the command's verbose output — most failures are schema interpretation, not code generation.