Bake Laravel Package

Getting Started

First, the framework boundary: cakephp/bake is CakePHP's code-generation plugin, not a Laravel package. There is no Laravel integration, no service provider, no artisan bridge. From a Laravel developer's chair the mental model is php artisan make:* crossed with reliese/laravel or kitloong/laravel-migrations-generator: it reads your database schema and scaffolds models, controllers, templates, tests, and fixtures from it. If you are not on CakePHP, this package has no day-to-day value for you — and the 112 stars are misleading, because bake ships with the cakephp/app skeleton, so almost nobody stars it standalone.

If you are on CakePHP (or evaluating a migration), the setup is nearly zero:

# already present in require-dev of the app skeleton; otherwise:
composer require --dev cakephp/bake

bin/cake bake --help            # list bake tasks
bin/cake bake model --help      # see flags for one task

Look at two directories before writing anything: vendor/cakephp/bake/src/Command/ (the real CLI surface and option names) and vendor/cakephp/bake/templates/bake/ (the Twig files that actually produce your code). Everything you will want to change lives in the second one.

The canonical first use case, after a migration has created a table:

bin/cake bake model Articles
bin/cake bake controller Articles --prefix Admin
bin/cake bake template Articles
bin/cake bake test controller Articles
bin/cake bake fixture Articles

# or all of the above in one shot:
bin/cake bake all articles

Run with -i if you want the interactive prompts (field selection, validation choices, association confirmation); without it bake takes the conventional defaults, which is what you want in scripts.

Implementation Patterns

Schema-first loop. Migrate → bake model → hand-edit the Entity/Table → bake controller and templates → bake tests and fixtures. Bake is a bootstrap step, not an ongoing generator; the value is the first 80% of boilerplate, and the remaining 20% is always hand-written.

Scaffold wide, keep narrow. bake all <table> is the fastest way to get a working CRUD screen for an internal/admin resource. For anything user-facing you will rewrite the Twig output anyway, so bake only the model, test, and fixture and write the views yourself.

Prefixed and plugin code. --prefix Admin puts controllers in src/Controller/Admin/ and views in templates/Admin/...; --plugin MyPlugin targets a plugin's namespace. bin/cake bake plugin MyPlugin generates the plugin skeleton itself, including its own bake templates if you want plugin-local overrides.

Customise via templates, not by editing output. Copy the relevant file from vendor/cakephp/bake/templates/bake/ into your app's templates/bake/ (mirroring the path) and edit it. Resolution order is app → theme → bake defaults, so app-level copies win. Bundle a set of overrides as a theme plugin and select it with --theme MyTheme; set the default once in config rather than retyping the flag.

Custom commands. Write src/Command/ReportCommand.php extending Cake\Bake\Command\BakeCommand, implement buildOptionParser() and execute(), and it is auto-discovered by the console like any other command. This is the right extension point for "our" resource shape (soft deletes, tenancy columns, audit fields) that the stock templates don't know about.

Scripted/CI use. Non-interactive plus --force inside a disposable checkout is a legitimate way to detect schema drift: regenerate, git diff, and see exactly which entities no longer match the database.

Trim the noise up front. --fields limits what gets generated; --no-validation and --no-rules skip baked rules so you can author them deliberately instead of deleting ninety lines of derived constraints.

Gotchas and Tips

• Overwrite semantics are destructive and silent-ish. Existing files are skipped unless you pass --force, and --force replaces the whole file with no merge. Never re-bake over code you care about without a clean git tree; the diff is your only safety net.
• A live database connection is mandatory for any schema-driven task (model, controller, all, test, fixture). Wrong or missing connection produces confusing failures or silently wrong types — use --connection when the default isn't the one holding the schema.
• Type inference is shallow. Enums, sets, JSON, unsigned integers, binary UUID primary keys, composite keys, and custom column types generally come out as strings or plain integers. Fix the entity's _accessible/cast types and the Table's initialize() afterwards; don't trust the baked version for anything but trivial schemas.
• Associations come only from real foreign-key constraints. Conventionally named columns without an actual FK are not detected. Add belongsTo/hasMany by hand and re-run bake test so the fixtures reflect it.
• Naming has to follow CakePHP conventions. Bake infers table class, entity class, and pluralisation from the table name; irregular plurals and legacy column names need explicit --table-class / --entity-class / --fields.
• Bake major must match the framework major. CakePHP 5 needs bake 5.x; a mismatched pair generates code against APIs that no longer exist.
• Read the template when output looks wrong. Every generated file comes from a specific .twig under templates/bake/; -v tells you what was written or skipped. Debugging the template is faster than debugging the artifact.
• Never edit vendor/cakephp/bake. Composer will eat it on the next update. App templates, a theme plugin, or a custom BakeCommand are the supported escape hatches.
• Baked templates are opinionated scaffolding (helper-heavy, Bootstrap-ish markup, generic pagination). Treat them as a reference implementation of CakePHP conventions rather than production views — they are actually a decent way to learn the framework's idioms if you're coming from Laravel.