Admin Generator Laravel Package

Product Decisions This Supports

• Build vs buy for scaffolding — now including admin UI, not just backend code. This package generates models, factories, form requests, permissions, and Vue views (Show.vue, Listing.vue). 2.5.1 confirms the output surface extends into our admin front end. The decision this informs is whether we own hand-rolled Laravel boilerplate and hand-rolled admin CRUD views, or adopt a generator plus its output conventions. Ownership cost shifts from "maintain templates" to "regenerate, diff, review" — but the review now covers presentation and escaping behavior, not just PHP.
• Rich-text rendering and sanitization ownership (new, 2.5.1). Generated Show.vue now renders wysiwyg columns (perex, text, body, description) with v-html instead of escaped text. That is the correct behavior for rich text, and it moves the escaping boundary: sanitization must happen where the content enters (server-side, at write time) or in a shared component. PM call: before regenerating views in any domain that stores user-authored content in those columns, confirm a sanitization policy exists. This is a security-reviewable change, not just a cosmetic one — treat it as a gated rollout item.
• Rollout sequencing for 2.4.0 factory states (still outstanding). Generated factory boolean states change casing: is_published now yields isPublished() / isNotPublished() instead of is_published() / notIsPublished(); single-word columns are unchanged (enabled() / notEnabled()). Already-generated code is untouched, so this remains opt-in-by-regeneration. PM call: regenerate per domain behind review, not big-bang, and budget test/seed updates for any suite calling the old snake_case states. Sequence this after the sanitization question above if the same domains have wysiwyg columns.
• Domain-model correctness. Stricter pivot detection means a table only becomes belongsToMany when it holds just its two foreign keys (plus optional id and timestamps). Entity tables that merely reference two other tables are no longer collapsed into pivots. This directly affects what our generated model claims about the schema — relevant to reporting joins, nested resource endpoints, and anything that consumed those relations.
• Legacy/renamed schema viability. #[Table(name: '...')] was being HTML-escaped, producing invalid PHP for non-conventional table names. Fixed in 2.4.0, and pivot table names/keys are read from detected schema rather than derived from convention. This widens the addressable use case from "greenfield, convention-compliant" to "existing schema."
• Low-risk noise in 2.5.1. User factory unverified(), two-factor, and password states now pass an array to state() instead of a closure, and a stale comment was removed from Listing.vue. No public surface change, no consumer action beyond regeneration. Useful mainly as a signal that factory internals are being tidied incrementally — no decision required.
• Extensibility / contribution model. AGENTS.md / CLAUDE.md and $view-based template resolution in request and permission generators suggest the project is positioned for AI-assisted contribution and template customization — worth noting if we plan to fork or override templates, especially now that view templates are in scope.

When to Consider This Package

Adopt when:

• You run a schema-first or DB-first workflow where models follow the database, and hand-maintaining model/factory/request boilerplate — plus the corresponding admin CRUD views — is a recurring tax.
• You're on a Laravel version that supports model attributes (#[Table], #[Fillable], #[Appends]) — the generator targets that style; on older versions the output won't match house conventions.
• Your schema includes non-conventional table names, since 2.4.0's schema-derived detection and the #[Table] escaping fix are what make those safe.
• Your rich-text columns have a defined sanitization path (write-time sanitization or a wrapper component), so v-html output in generated Show.vue is safe by construction.
• You can treat generated code — PHP and Vue — as regenerable and review regeneration diffs in PRs. The package is only cheap if regeneration is routine and tested.

Look elsewhere or wait when:

• You can't absorb the factory-state rename yet. It shipped in a minor version, but regenerating a factory changes that factory's public surface; any test or seeder calling is_published() breaks. If factory coverage is thin or the codebase is large, pin to 2.3.x until a controlled sweep is scheduled.
• You store untrusted HTML in text/body/description/perex and have no sanitization layer. Regenerating Show.vue on 2.5.1 would turn a latent data-quality issue into a live XSS surface in internal admin tooling. Fix the sanitization path first, then regenerate.
• You want entity tables that reference two tables to be treated as relations — 2.4.0 intentionally stops doing so; validate the new behavior against your domains before broad rollout.
• Your admin views are hand-designed rather than generated. Overriding Show.vue / Listing.vue means maintaining a fork of a template that is actively changing; if the design system diverges far from generated output, the front-end half of this package becomes a liability rather than a saving.
• You need runtime capability (query building, serialization) rather than code generation — this is a scaffolding tool, not an ORM feature.
• You require vendor stability guarantees. Minor and patch releases altering generated output casing, escaping behavior, and factory internals signal that generated artifacts aren't covered by semver the way consumers might assume.
• You need the full 2.4.0 → 2.5.1 picture. 2.5.1 notes cover only its own delta and reference no 2.5.0 changes; confirm nothing was shipped in between before planning a regeneration sweep.

How to Pitch It (Stakeholders)

Executives: This is a developer-productivity dependency that turns our database schema into Laravel models, factories, requests, permissions, and admin CRUD views. Release 2.4.0 was a quality release — it fixed generation of invalid PHP for non-standard table names and stopped misclassifying ordinary tables as many-to-many pivots, which was producing incorrect domain models. Release 2.5.1 is smaller: generated admin views now render rich-text columns as formatted HTML rather than escaped markup, which is what editors expect but requires us to confirm our content sanitization before regenerating those views. There is one controlled migration cost carried over from 2.4.0 — regenerated factories rename boolean helper methods to camelCase — so we regenerate per domain with tests updated alongside rather than all at once. Nothing breaks on upgrade: existing generated files are untouched until we choose to regenerate.

Engineering: Upgrade is safe at install time; existing generated code is not modified. Treat regeneration as a reviewed change: pin the version, regenerate into a branch, diff output. Expect factory states to move from is_published() / isNotPublished() to isPublished() / isNotPublished() (single-word columns unchanged), and note generated closures are now static fn (): array without phpcs:ignore, so coding-standard configs may need a look. Pivot detection is FK-only (plus optional id/timestamps) with names and keys read from the schema, #[Table] is emitted after #[Fillable] (after #[Appends] on admin users), and the double-blank-line issue between consecutive generated hasMany methods is fixed. In 2.5.1 specifically: Show.vue renders perex, text, body, and description via v-html — confirm server-side sanitization for those columns before regenerating any view that displays user-authored content, and prefer an allowlist sanitizer over trusting the column name; user factory unverified(), two-factor, and password states now pass an array to state() rather than a closure (no external behavior change); and a stale comment above useResponsiveColumns() in Listing.vue was removed. Snapshots were regenerated and relation/factory/model generation gained new tests, so the diff surface is well covered.