yab/laracogs
Laracogs is a Laravel scaffolding toolkit that speeds up development with generators for CRUD, Bootstrap, forms, and more, plus ready-made helpers and traits so you can skip repetitive boilerplate and focus on building your application.
Laracogs is a scaffolding toolkit for Laravel 5.x (it was last released in August 2017 and is archived), so treat it as a legacy code-generator rather than a runtime dependency. Its value is in the laracogs:* Artisan commands that emit migrations, models, controllers, routes, views and tests from a single field definition, plus a set of form/input helpers for Blade.
Minimal setup in a throwaway Laravel 5.4/5.5 app:
composer require yab/laracogs
Register the provider (manually on 5.4, or rely on package discovery on 5.5):
// config/app.php
Yab\Laracogs\LaracogsProvider::class,
Publish the config and any assets, then inspect what shipped:
php artisan vendor:publish --provider="Yab\Laracogs\LaracogsProvider"
php artisan list | grep laracogs
Where to look first: config/laracogs.php (namespaces, paths, theming, enabled generators) and the package's src/Stubs / src/Console directories. The stubs are the real specification — everything the commands produce is a template you can read and override, and version-to-version drift shows up there first.
First use case: scaffold a throwaway posts resource end-to-end before touching a real project. Run the CRUD generator, php artisan migrate, and click through the generated index/create/edit pages. You'll learn in ten minutes exactly which conventions the tool assumes (layout name, route naming, auth middleware, form helper usage) and whether they match your app. If they don't, decide now whether to override stubs or abandon the generator.
Config-driven CRUD generation. The core workflow is: describe a table's fields once, let Laracogs emit the full stack, then hand-edit. A typical invocation looks like:
php artisan laracogs:crud --table=posts --fields="title:string,body:text,published:boolean"
(The exact flag names vary by version — check php artisan help laracogs:crud for your install.) The generated set usually includes a migration, an Eloquent model, a controller, route entries, Blade views, and a feature test. Run it on a clean branch and commit the raw output first, so your subsequent edits are a reviewable diff against the generated baseline.
Generate, then own the code. Laracogs is a one-shot generator, not a runtime framework. The healthiest pattern is to treat generated files as a starting point you immediately take ownership of: add validation rules, policies, relationships, casts, and index definitions by hand. Do not plan to re-run the generator over files you've already customized — regenerating is best reserved for brand-new resources.
Pair it with the bundled form/input helpers. The generated views lean on the package's form and input builders to render fields consistently:
{!! FormMaker::fromTable('posts', Config::get('laracogs.forms.posts')) !!}
or the per-field variant with InputMaker. The win is that form markup stays in sync with the field list you used to generate the CRUD; the cost is that the helpers are opinionated about Bootstrap-era markup. If your front end is Tailwind or a component library, you'll end up replacing these with your own partials and treating the generated views purely as a structural reference.
Override stubs instead of editing vendor files. The main extension point is publishing/copying the stub templates and pointing the config at your copies. Change the stub once (layout name, namespace, base controller, test namespace) and every future laracogs:crud run inherits the change. This is the single highest-leverage customization and worth doing on day one.
Wrap it in your own command for team conventions. If you scaffold often, a thin internal Artisan command that sets defaults (namespace, layout, middleware, field presets) and delegates to the CrudMaker service keeps generated code consistent across developers, rather than relying on everyone remembering the right flags.
Integration tips.
use statements.auth group rather than trusting the generated route file verbatim.php artisan route:list and php artisan view:clear after every generation pass; stale compiled views are a common source of "the generator didn't work" confusion.It is archived and Laravel-5-only. Last release August 2017. Do not attempt to install it in Laravel 6+ or on PHP 8 — you'll hit Illuminate version constraints and PHP incompatibilities (dynamic properties, each()-era helpers, old Symfony console APIs). For anything modern, this package is a reference implementation to read, not a dependency to add. If you're maintaining a 5.x app, pin the exact version and vendor it if needed.
Regeneration overwrites files. The generators write into existing paths. Always generate inside a clean working tree so git diff tells you exactly what changed, and never run a generator against a resource you've already customized unless you've verified the overwrite behavior for your version.
Stub drift against your app. Generated code assumes a layout (layouts.app or similar), a base Controller, and helper aliases that may not exist in your project. Expect a handful of "class not found" / "view not found" errors on first run — these are wiring gaps in the stubs, not bugs in your app.
Facade and alias collisions. Laracogs registers facades with fairly generic names (FormMaker, InputMaker, CrudMaker, Bootstrap). If you already have a form builder or a Bootstrap helper, alias them to something namespaced to avoid a confusing resolution order bug.
Migration types are generic. The generator emits plausible column types but rarely the right lengths, indexes, nullability, or foreign keys. Treat the generated migration as a sketch and edit it before running migrate, especially for anything with a unique constraint or a relation.
Security is not generated. CRUD scaffolds give you permissive controllers. Add authorize() calls / policies, request validation, and mass-assignment $fillable review yourself. This is the most common way Laracogs-based apps ship an accidental hole.
Debugging checklist when a generated resource misbehaves: confirm the provider and facades are registered → php artisan route:list | grep <resource> → check the published config paths actually point where you think → compare the output file against the stub it came from (that diff localizes the problem immediately) → view:clear and config:clear.
Extension points, in order of value: published stubs → published config (namespaces/paths/theming) → your own wrapper command → subclassing the service classes. Avoid editing anything under vendor/; you'll lose it on the next composer update, and with an archived package there will be no upstream fix if you break it.
How can I help you explore Laravel packages today?