Admin Generator Bundle Laravel Package

Getting Started

Before anything else: verify what you actually have. The -bundle suffix is Symfony’s namespace convention, not Laravel’s, so the first step is to open composer.json and read the type and require blocks. If type is symfony-bundle, composer require into a Laravel app will not register a service provider, will not bind into Laravel’s container, and will not integrate with Eloquent or Blade without an adapter you write yourself. Realistically, "getting started" means one of three paths:

1. You are on Faros (Symfony). Register the bundle in config/bundles.php, publish/configure the entity mapping, then run the generator command against a single, low-risk model. Inspect every emitted file (controller, routes, list/form views, config) before touching a second entity.
2. You are on Laravel and want CRUD scaffolding. Stop. Redirect to Filament, Laravel Nova, Backpack, or raw php artisan make: commands. The package emits Faros-shaped code, not Laravel-shaped code; the rework would exceed writing the CRUD by hand.
3. You are scoping an in-house admin generator. Treat the repo as reference material: skim the templates directory first — that is where the actual shape of generated controllers, views, and route definitions lives, and it tells you in five minutes whether the design is close enough to yours to borrow ideas from.

Where to look first, in order: composer.json (framework and PHP constraints), the templates directory (output shape), then any config file (how entities map to generated artifacts). There is no README worth reading. The first use case is a single model, generated once, diffed against a hand-written equivalent, so you can quantify exactly how much rework a real Laravel controller would need.

Implementation Patterns

If you are in a Faros context and using this day-to-day:

• Entity-in, artifact-out, checked into VCS as a single commit. Generate for one entity, commit the raw output as its own commit, then hand-edit. This makes later regeneration diffable instead of a blind overwrite.
• Customize templates, not generated files, when you expect to regenerate. If the generator will run repeatedly, the templates directory is your extension point. Post-editing generated files and then regenerating is the classic "lost my changes" workflow.
• Layer extensions on top of generated classes rather than editing them in place — subclass, trait, or decorator patterns keep the generated artifact replaceable if the templates change.
• Establish a naming map before generating anything. Entity → controller → route → view naming is the contract between the generator’s output and the rest of your app. Write it down once; it removes most "why is this route called that" archaeology later.
• Run the generator against a sandbox schema first. Because generated output multiplies, a template defect propagates across every entity you run it against. One clean run against a disposable entity is cheap insurance.
• Port patterns, not code, to Laravel. The search/filter/pagination logic is conventional resource-controller material — translate it into Eloquent query scopes and a resource controller rather than trying to shim the emitted code. This is the only pattern from the package that routinely transfers cleanly.

Gotchas and Tips

• Framework mismatch is the headline gotcha. Symfony bundle conventions mean you cannot consume this in a Laravel app without writing a compatibility layer — which by definition defeats the purpose of a scaffold generator.
• "Generator for Faros" means domain-coupled output. Emitted code will assume Faros admin abstractions. Even if you got it booting under Laravel, the generated controllers would reference things Laravel doesn’t have.
• Archived means no patches. No security advisories, no PHP minor-version compatibility, no upstream bug fixes. Running it under a current PHP runtime is a likely source of silent incompatibility — the generator runs, emits subtly wrong code, and you find out in review or production.
• Regeneration over your edits is the trap. Any generator that writes into your tree will eventually overwrite hand edits. Either treat output as append-only with explicit fork points, or accept that regeneration costs a manual merge every time.
• Debug in the templates, not the output. When a generated controller is wrong, the fix is in the template. Debugging the emitted file fixes one instance; the next run reintroduces the bug.
• Zero dependents, zero stars, zero docs. There is no Stack Overflow corpus, no example projects, no maintainer to ask. Every "why does it do X?" is answered by reading source. Onboarding cost is per-engineer and does not amortize.
• No tests means unspecified behavior. Every generated artifact must be verified individually — you cannot assume the generator handles edge cases (empty relations, soft deletes, composite keys) that a tested scaffold would handle.
• Extension points to preserve if you fork it: the template directory and the entity-mapping config. Everything else is disposable; these two are the parts that carry the design intent and are worth keeping if you rebuild the concept in-house.
• The pragmatic advice: if a ticket proposes this package for a Laravel project, the correct response is to rewrite the ticket against Filament, Nova, Backpack, or Orchid, and cite the same feature scope. The only defensible use of lephare/admin-generator-bundle is as prior art when designing an equivalent generator for the stack you actually run.