Admin Generator Laravel Package

Getting Started

This package generates Laravel artifacts — models, factories, requests, permissions, and admin Vue pages — from your database schema. The generator surface has been stable since 2.4.0; 2.5.1 again changes only what it emits. Pin expectations before you regenerate anything.

1. Install and publish config/templates (php artisan vendor:publish), then read the generator classes and templates first — template resolution lives on the $view property for the request and permission generators, so that's the canonical place to see what output you'll get.
2. If you use coding agents, read AGENTS.md / CLAUDE.md before letting an agent run generators — they encode the conventions the package expects and keep agents from hand-editing generated files.
3. First use case: pick one table with a snake_case boolean column, one pivot table, and one wysiwyg column (perex, text, body, or description) used by a generated admin Show.vue. Run the generator and diff the output against what you have committed. That single run exercises the 2.4.0 factory/relation changes plus the 2.5.1 v-html rendering change.

Do this on a clean working tree. Existing generated code is untouched by upgrades; the diff is your migration plan.

Implementation Patterns

Regenerate in reviewable units. Generate one model, factory, or Vue page at a time and commit the output alongside the call-site changes it forces. Bulk regeneration makes the 2.4.0 factory rename and 2.5.1 rendering changes impossible to audit.

Boolean states in tests. Generated factories expose camelCase states for snake_case columns:

// is_published column
Post::factory()->isPublished()->create();
Post::factory()->isNotPublished()->create();

// single-word column, unchanged
User::factory()->enabled()->create();
User::factory()->notEnabled()->create();

Multi-word columns gain camelCase and the negation is isNotX(); single-word columns keep the older enabled() / notEnabled() shape. Wrap these in your own factory helper methods if you want one naming convention across the codebase.

Let relation detection be data-driven. As of 2.4.0, a table is treated as a belongsToMany pivot only when it contains just its two foreign keys plus optional id and timestamps. Pivot table names and key columns are read from the detected schema rather than derived from naming conventions. In practice:

• Keep genuine pivots minimal — extra columns demote them to entity tables.
• When a join table carries payload (role, assigned_at, status), expect a hasMany to a real model instead of belongsToMany, and model it explicitly.
• After regenerating, verify relation method names and key arguments on both sides; schema-derived keys can differ from what convention previously produced.

Non-conventional table names. Use #[Table(name: 'legacy_orders')] on the model. The 2.4.0 fix means this attribute now generates valid PHP instead of HTML-escaped output, so models with off-convention table names are safe to regenerate. Attribute ordering is now #[Fillable] → #[Table] (and #[Fillable] → #[Appends] → #[Table] for admin users); match that order if you hand-maintain any models.

Wysiwyg columns are rendered as HTML in admin pages. As of 2.5.1, generated Show.vue renders perex, text, body, and description via v-html instead of escaped text. That is the intended display change, but it moves escaping responsibility to your content pipeline. Sanitise content stored in those columns before it reaches the admin UI, or override the published template.

Swap templates rather than patching output. With the $view property on request and permission generators — and the published Vue templates — you can point a generator at your own template to change output shape permanently. Prefer that over post-generation edits, which get clobbered on the next run and don't survive snapshot regeneration.

Gotchas and Tips

The 2.4.0 factory rename is still the breaking change on regeneration. is_published() / notIs_published() become isPublished() / isNotPublished(). Existing generated factories keep working until you regenerate them — the break lands the moment you do, in every test and seeder that calls the old state. Grep your test suite for snake_case state calls before regenerating a factory, not after.

2.5.1 changes are regeneration-triggered too. Release notes are explicit that existing generated code stays as it is. Nothing breaks on composer update; rendering and factory-shape changes land on the next generate. Treat regeneration as a deliberate, isolated commit.

v-html is not sanitisation. Regenerated admin Show.vue pages no longer escape wysiwyg columns. If those columns can contain user-supplied HTML, sanitise on write or at render time with a trusted sanitiser before regenerating. Audit perex, text, body, and description usages specifically.

Pivot detection can silently remove relations. An entity table that references two other tables used to be turned into a belongsToMany. It no longer is. Regenerated models may quietly lose a relation method — that's a BadMethodCallException in production, not a compile error. Diff regenerated models specifically for missing belongsToMany methods, and re-add them by hand where the old heuristic happened to be right.

Convention-derived vs schema-derived pivots. If your pivot naming was irregular but your conventions papered over it, the schema-derived names may differ. Check the generated belongsToMany signatures for table and key arguments after regenerating.

Whitespace, attribute churn, and comment removal will dominate your diff. Two blank lines between consecutive hasMany methods, the #[Table] repositioning, and 2.5.1's removal of the long useResponsiveColumns() comment in Listing.vue are noise. Review those hunks first so real semantic changes — relation loss, state renames, v-html rendering — aren't buried.

User factory state closures became arrays. In 2.5.1 the generated unverified(), two-factor, and password states pass an array to state() instead of a closure. Same behaviour, different output shape; don't mistake it for a functional change. If you carry local patches around those states, reapply them against the array form.

Drop stale phpcs:ignore comments. The new boolean states use static fn (): array closures and no longer need them. If you carry local patches, remove the suppressions so your linter still catches genuine issues.

Debugging generator output: inspect the resolved $view on the generator, then the template, then the schema detection — in that order. Snapshot tests in the package cover relation detection, factory/model generation, and Vue output; if your output looks wrong, compare against the expected snapshot shape rather than guessing.