Generator Builder Laravel Package

Getting Started

This package is a development-time scaffolding tool, not a runtime dependency. The mental model that makes it click: it is make:model / make:controller with a browser form in front of it. You use it during feature construction, commit the generated files, and the package then mostly sits dormant in composer.json. Plan your workflow around that, not around "integrating a library".

Install the ecosystem, not just this package. Generator Builder is the UI; it shells out to infyomlabs/laravel-generator for the actual scaffolding, and that generator needs a template package (e.g. infyomlabs/adminlte-templates, infyomlabs/bootstrap-templates) to produce views. composer require infyomlabs/laravel-generator infyomlabs/generator-builder plus your chosen template package is the minimum set.

Do the install in a scratch Laravel app first. The last tagged release is from 2022 and there is exactly one tag (v1.0.0). Read the composer.json constraints of both laravel-generator and generator-builder before touching your product repo — this is where you find out whether your Laravel version is actually supported, and it is far cheaper to discover that in a throwaway project than halfway through wiring the builder into an existing app.

Publish config and templates:

php artisan vendor:publish --provider="InfyOm\Generator\InfyOmGeneratorServiceProvider"
php artisan vendor:publish --provider="InfyOm\GeneratorBuilder\GeneratorBuilderServiceProvider"
php artisan vendor:publish --tag=templates   # generator template stubs

Then read config/generator_builder.php top to bottom. The keys that matter day-to-day are the route prefix, the middleware stack guarding the builder, and the template mappings (which template package produces web vs. API output). Laravel 11+ auto-discovers the provider if extra.laravel.providers is declared; otherwise register it manually.

First use case to validate end-to-end: open the builder at the configured prefix (commonly /generator) in a logged-in browser session, define a small throwaway model — a Post with title:string, body:text, published:boolean, and a user_id belongsTo User — pick a template, and click generate. Then walk the diff: migration, model, controller, repository, form request, appended routes, and Blade views. If all of that lands and the CRUD page renders, you have a working install. If the generate request hangs, 500s, or silently does nothing, stop and debug there — do not start defining your real schema until the round trip is green.

Check the route prefix early too. If the builder page 404s, the provider is not registered or the config is cached against an older prefix; php artisan config:clear and route:list | grep -i gener will tell you which.

Implementation Patterns

Gate the builder behind admin middleware and keep it out of production. This is the single most important pattern. The builder writes files and appends to routes/web.php/routes/api.php on demand; exposing it on a public host is a remote code-generation endpoint. Put auth + an admin gate (or can:manage-scaffolding) in the builder's middleware config, and consider ->middleware('env:local') style guards so the route does not even register on production. If it must run on a shared staging box, put HTTP Basic auth in front as well.

Design → generate → review → refactor → commit, in that order. Treat generated code as a starting point the same way you treat make:model output. The builder's rollback tracking works on files it created; once you hand-edit them, rollback either deletes your work or refuses. So the clean workflow is two commits: one "generated scaffold (untouched)" and a follow-up with your real business logic. That keeps rollback viable and makes code review of the scaffold trivial.

Use the CLI for repeatability and the UI for iteration. The browser form is great for exploring a schema, but it is not reproducible: the field definitions live in the builder's storage, not in your repo. Two habits fix that:

• Export the field definition JSON the builder produces and commit it under something like resources/generators/post.json, then re-run with php artisan infyom:scaffold Post --fieldsFile=resources/generators/post.json. Now schema changes are code-reviewed diffs rather than someone's browser memory.
• For anything scripted (demo apps, seeds, CI smoke tests), call the artisan commands directly and skip the builder entirely. The builder is a thin wrapper around infyom:scaffold and infyom:rollback.

Generate parent tables before children. A belongsTo field assumes the referenced table exists when the migration runs; a hasMany/belongsToMany relationship assumes the child model and its foreign key. Generate User-style parents (or anything with FK targets) first, then the models that point at them. If you got the order wrong, roll back the child and regenerate rather than hand-patching migrations.

Pick a template package deliberately and stick to it. Web vs. API output differs substantially — API templates skip Blade views and add resources, tests, and routes/api.php entries; web templates assume a layout (AdminLTE, Bootstrap) that your app may not use. Mixing templates halfway through a project produces a codebase where some modules use repositories and others do not. Decide once per project.

Bend templates, not generated output, for cross-cutting changes. If every generated controller needs the same trait, the same logging, or the same base class, publish the template stubs and edit them, then regenerate. It is more work up front than editing ten generated controllers, but only the template version survives the eleventh module. When you do customize a template, add a header comment noting it is a local modification — vendor:publish --force will otherwise silently overwrite it.

Keep the builder's own bookkeeping in version control if you rely on rollback. The generator records what it produced so infyom:rollback knows what to delete; that log typically lives under storage/ and is easy to gitignore by accident. If you lose it, rollback silently degrades to manual git checkout. Committing it is cheap insurance.

Pair with the rest of your dev workflow. Generated controllers/repositories are meant to be extended, not fought. Keep your service-layer, policies, and tests in files the generator does not touch, and depend on those from the rest of the app — the same adapter instinct you would apply to any vendor library, except here the "vendor library" is a code emitter and the adapter is just "the layer above the generated controller".

Gotchas and Tips

• Route appending is the classic pain point. Each run appends Route::resource(...) and the use import to routes/web.php or routes/api.php. Regenerating without rollback produces duplicate routes and duplicate imports. Rollback removes what it recorded, but if you hand-edited the routes file between runs the cleanup can miss. Check route:list after every generate/rollback cycle.
• Rollback is not git revert. It deletes files the builder tracked and does not know about anything you created afterwards. Never run rollback on a dirty working tree; commit first so you have a diff to inspect and a one-command escape hatch.
• Configuration and route caching will mask changes. After editing config/generator_builder.php or regenerating routes, run php artisan config:clear && php artisan route:clear && php artisan cache:clear. In production, config:cache must be re-run on deploy after any config change, or the builder may appear enabled/disabled depending on what was cached last.
• Version compatibility is the real risk of a 2022 single-tag package. Before adopting, check the composer.json constraints of generator-builder against your Laravel version, and check whether the generator's own composer.json allows the same range. If you are on a newer Laravel than the package claims, do not paper over it with --ignore-platform-reqs in production — pin Laravel for that project, or maintain a fork with widened constraints and record it.
• The generate request runs synchronously inside the HTTP request. Large models, slow disks, or a big template set can exceed PHP's max_execution_time and produce a blank response or a partial file set. If you hit that, generate in smaller batches or call infyom:scaffold from the CLI instead of the browser.
• Validation rules defined in the UI are limited. Custom rules, conditional unique/exists, regex patterns, and cross-field rules usually need to be added by hand to the generated FormRequest afterwards. Plan for a manual pass and keep those edits in the post-generation commit, not the scaffold commit.
• Enum/foreign-id ordering matters in the database. Generating a migration with a foreign key to a table that does not exist yet will fail on migrate. If you see the FK error, the fix is usually "generate the parent first", not "hand-edit the migration to drop the constraint".
• The generated code is your code the moment it lands. Bug fixes, refactors, and naming conventions apply to it exactly as to hand-written files. Do not leave files untouched just because the tool made them; and do not assume a re-run will preserve your edits — it will not.
• Check the route prefix before assuming the package failed. If /generator 404s, look at config/generator_builder.php and php artisan route:list, then at the provider registration. It is almost always a prefix mismatch or a cached config.
• Never edit vendor/infyomlabs/... directly. If you need to change the generator or the builder itself, fork on a VCS repository or use cweagans/composer-patches, and record the patch in the repo. Composer will erase anything else on the next update.
• Watch whether the generated code is tracked anywhere else the team assumes. Because the builder holds the field definitions and the generator holds the rollback log, two developers can have different "current schema" views of the same project. The checked-in JSON fields file is the fix; make it part of the PR checklist for schema changes.
• Upgrade on a branch with a clean scaffold test. When a new tag eventually appears, run the "Post" smoke test above on a branch before adopting it, and inspect the generator output diff — template drift between minor releases is the most likely source of surprise here.