- How do I install dejwcake/admin-generator in a Laravel application?
- Install it with Composer using the package name dejwcake/admin-generator. Because it is a development-time code generator rather than a runtime library, most teams add it as a require-dev dependency so it never ships to production. Check the package's composer.json for the exact PHP and Laravel constraints before installing, then run your usual generator command from the console. Commit the generated files, not the generator, if your deployment pipeline does not run Composer dev dependencies.
- What does dejwcake/admin-generator actually generate?
- It scaffolds the typical pieces of a Laravel admin interface from your existing models: models themselves, factories, form requests, permission entries, and CRUD resource scaffolding. Generated models use PHP 8 attributes such as #[Fillable], #[Appends], and #[Table] instead of the usual property arrays, and relations are derived from introspecting your database schema. The output is plain PHP you own and can edit freely, so there is no runtime dependency on the package once generation is done.
- Which PHP and Laravel versions does admin-generator support?
- The package emits PHP 8 attributes, so a PHP 8 runtime is a hard requirement. Laravel version support is declared in the package's composer.json, so read the constraints there rather than assuming it matches your app. If you maintain multiple Laravel versions, pin the generator per branch and run a generation smoke test in CI to catch constraint drift early.
- Is it safe to run dejwcake/admin-generator in production?
- It is a build-time tool, not part of the request path, so architectural risk is limited to code authoring and CI. Keep it in require-dev and run it locally or in a dedicated pipeline step, never on a live server. Generated code continues to run independently, and upgrading the generator does not modify code you have already generated.
- Is version 2.4.0 a breaking change even though it is a minor release?
- Yes in practice: 2.4.0 is a minor version but it changes generated output, including factory state method names and relation detection. The maintainer's position is that codegen output is not public API, but for your team it means a routine composer update can invalidate tests the next time you regenerate. Treat generator upgrades as major-version events internally, regenerate on an isolated branch, and review the diff before merging.
- Why did my generated model lose its belongsToMany relation after upgrading to 2.4.0?
- Version 2.4.0 tightened pivot detection and now derives pivot table names and keys from the actual schema instead of guessing from naming conventions. Tables that merely reference two other tables are no longer coerced into belongsToMany, so a model may now expose hasMany or belongsTo instead, or no relation at all. This can still compile, so verify query semantics, deduplication, and eager loading on any model backed by a two-foreign-key table. Diff those models explicitly rather than accepting the regenerated output blindly.
- Why am I getting a BadMethodCallException for is_published() in my tests?
- Generated factories rename boolean states for snake_case columns from is_published() and notIs_published() to isPublished() and isNotPublished(). Single-word columns such as enabled() and notEnabled() are unchanged, so the failure only hits multi-word flag columns. The break is loud rather than silent, which is good: the fix is a mechanical update of call sites in tests. Scope the change to factories regenerated on or after 2.4.0.
- Do I need to re-publish generator stubs or views after upgrading?
- Possibly. Version 2.4.0 refactored generators so each one resolves its template through a $view property, which implies the template resolution path moved. If you have published generator stubs or views and customised them, your overrides may silently stop being used while generation still succeeds. Re-publish the stubs, diff them against your customised copies, and add a snapshot test so a stale override fails loudly next time.
- Why does generated code differ between my local machine and CI?
- Because pivot names and keys are now introspected from the connected database, generation output depends on which database the generator talks to, whether that is local, CI, or a shadow database. The old convention-based behaviour was predictable regardless of connection; the new behaviour is more accurate but environment-coupled. Run generation against a consistent schema and compare artifacts in CI to confirm reproducibility before tagging a release.
- How do I fix invalid PHP generated for non-conventional table names?
- That was caused by the #[Table(name: '...')] attribute not escaping its value, which produced broken PHP for table names containing characters that need escaping. Version 2.4.0 adds HTML escaping, so upgrading unblocks anyone previously hard-blocked on unconventional table names. If you cannot upgrade yet, the practical workaround is renaming the table or hand-editing the attribute after generation.