Rad Bundle Laravel Package

Getting Started

Read this first: smart-core/rad-bundle is a Symfony bundle, not a Laravel package. The description says "drop into an existing Laravel app," but the repository is a Symfony Bundle — it registers services into Symfony's DI container, hooks the HttpKernel lifecycle, ships Extension/CompilerPass classes, and is discovered via config/bundles.php. There is no RadBundleServiceProvider, no config/rad.php merge, no php artisan vendor:publish. composer require smart-core/rad-bundle in a Laravel app will install fine (Composer does not check framework fit) and then do nothing for you. The realistic "getting started" is a 1–2 day reference-design spike, not an install.

Where to look first (in the repo, not your app):

1. composer.json — the require block is the whole story. Pin down php, symfony/*, and whether it hard-requires doctrine/orm and symfony/form. This tells you its era and how much of it is Doctrine-coupled.
2. src/RadBundle.php and DependencyInjection/Configuration.php — the config tree is the heart of the "config-driven resources" claim. This is the file you are actually reading the package for.
3. src/Command/ — the generator entrypoint(s), arguments, and options (--force, --dump, --dry-run if present).
4. skeleton/, Resources/skeleton/, or templates/ — the stubs. These are the artifact you would port verbatim into resources/stubs/.
5. Resources/config/routing.* / routing attributes — how generated routes get registered. In Laravel that's a Route::resource() call or one line in routes/web.php, so this section is mostly noise for you.

First use case: stand up a throwaway Symfony skeleton (symfony new rad-spike), install the bundle, and generate one resource — say Invoice with number, amount, status, issued_at. Then open every generated file and write down five things: (a) which files are fork-on-write vs regenerable, (b) where validation lives, (c) how authorization is expressed, (d) whether a factory/seeder equivalent is emitted, (e) whether tests are emitted at all. That five-line diff against your own Laravel conventions is the entire deliverable.

The Laravel equivalent, in priority order: Filament (admin panels + forms, actively maintained), Laravel Nova (paid, supported), Backpack, or — if you only want the generator and not the admin UI — a ~200-line in-house Artisan command with published stubs. Do this before reading the bundle if your actual requirement is "we need CRUD faster," not "we need to study prior art."

Implementation Patterns

Pattern 1: port the resource definition, drop the runtime. The only genuinely portable idea here is the single-file resource manifest. Reproduce it as YAML or PHP under resources/rad/ (not config/, so it isn't flattened by config:cache):

// resources/rad/invoice.php
return [
    'model' => 'Invoice',
    'fields' => [
        'number'    => ['string', 'unique', 'index'],
        'amount'    => ['decimal:10,2'],
        'status'    => ['enum', ['draft', 'sent', 'paid'], 'default:draft'],
        'issued_at' => ['timestamp', 'nullable'],
    ],
    'belongs_to' => ['customer'],
    'timestamps' => true,
    'soft_deletes' => true,
];

Then one php artisan rad:make resources/rad/invoice.php fans out to Model + Migration + FormRequest (store/update) + Policy + Controller + Factory + a Route::resource line. That is the entire value proposition, and it is maybe 300 lines of PHP to build — which is the honest comparison against adopting a 0-star foreign-framework bundle you would have to own.

Pattern 2: fork-on-write with an explicit ownership boundary. RAD generators fail at the second schema refactor unless you decide this up front. Two workable models:

• Fork-on-write (recommended). Generate once, then the file is yours. Stamp every generated file with a header — // @generated by rad:make at {ISO8601} — safe to edit, will not be overwritten — and keep a rad.manifest.json listing generated paths so a rad:drift command can flag "edited since generation."
• Idempotent regeneration. Only viable if every generated file has a stable, fully-specified target and no hand edits. In practice this survives about one sprint.

Never mix the two. The failure mode is a teammate regenerating a controller and silently reverting two days of hand edits.

Pattern 3: stub overriding via publish, not vendor edits. Symfony bundles do stubs via an overridable skeleton path; Laravel does it via vendor:publish --tag=rad-stubs writing into resources/stubs/rad/. Resolve stubs with resource_path('stubs/rad/'.$name) falling back to __DIR__.'/../../stubs/'.$name. Mirror that convention exactly, because "customize the stub once, every future module inherits it" is the feature that makes a generator worth having.

Pattern 4: generate into a scoped namespace, never app/ root. app/Modules/Invoice/{Models,Migrations,Controllers,Requests,Policies} with a Modules\\Invoice\\ PSR-4 root registered in composer.json. Blast radius control matters more than elegance — a generator that can write anywhere in app/ is a generator that can collide with hand-written code during a rebase.

Pattern 5: CI idempotency gate. Generate into a temp directory in a pipeline job and git diff --exit-code. This catches stub drift when the framework or your conventions change, and it is the cheapest protection you get once a team depends on a generator.

Symfony → Laravel translation table for the spike:

Gotchas and Tips

The framework mismatch is the whole assessment. Do not spend a sprint on a shim — installing symfony/* components and Doctrine alongside Eloquent to bridge a code generator produces a two-container, two-ORM application whose failure modes are subtle and whose onboarding cost is permanent. There is no runtime behavior to bridge here; the bundle's output is plain PHP files that you could write yourself. Treat it as a design document.

Zero stars, zero dependents, zero Packagist dependents. For a generator this is worse than for a runtime library: abandoned generators keep emitting plausible-looking code that silently drifts from current framework APIs. If you take anything from the repo, vendor or copy it — do not add it to composer.json as a runtime dependency you expect upstream to maintain.

The registry metadata is wrong. It is filed under Laravel tooling and it is a Symfony bundle. That mislabeling is itself a signal about how much you should trust the surrounding metadata (including the 8.32 opportunity score, which appears derived from the description text rather than usage).

Doctrine assumptions leak everywhere. If the generator's controller stubs call $entityManager->persist() / getRepository(), or the stubs use annotation-based mapping, they will not port 1:1 — you are rewriting the stub bodies against Eloquent, not translating them. Budget for rewriting stubs, and count that as the real cost of "reusing" the package.

Check the Symfony version pin before copying any idiom. AbstractBundle + configure() means Symfony 6.1+; Extension + Configuration tree means it may target 3.x/4.x and use deprecated APIs (getDoctrine(), annotations, @Route). Old idioms port into Laravel as old idioms — you do not want YAML-driven validation in a Laravel 11 codebase.

Generators and Laravel config caching. If you model the config as config/rad.php, remember php artisan config:cache flattens it and env-dependent keys become null after caching. Resource manifests belong in resources/ or a dedicated rad/ directory read at command time. For the Symfony original, the equivalent trap is that bundle extension config is compiled once — a container rebuild is needed after changes, and a stale cache is the first thing to suspect when a generator ignores your config.

Guard against destructive regeneration. Require --force to overwrite an existing file, print a git status --porcelain warning, and refuse to run outside local unless explicitly allowed. Migration timestamp collisions (2024_01_01_000000_*) are a real source of "my migration didn't run" confusion when several resources are generated in the same second — namespace the timestamps (date('YmdHis').'_'.$index) or generate one at a time.

Naming collisions are the top day-to-day annoyance. Invoice model, InvoiceController, InvoicePolicy, InvoiceRequest, InvoiceFactory — plus plural route names, table names, and InvoicePolicy auto-discovery relying on exact App\Models\Invoice → App\Policies\InvoicePolicy convention. Under a Modules\ namespace, Laravel's policy and factory auto-discovery will not find them; you must register Gate::policy() and override newFactory() explicitly in the generated model, or the generator's output will fail authorization silently (returning 403 for reasons nobody can trace). Emit those registrations in the stub.

Extension points worth reproducing: stub override directory, a --fields style inline definition for one-offs, a --dry-run that prints the diff, and a --no-interaction path for CI. These four are what separate a generator the team uses from one they route around.

The maintenance tax arrives at the second refactor, not the first. Scaffolding is cheap when the schema is stable and expensive the moment it churns. Decide explicitly whether generated modules are frozen after generation (fork-on-write, hand-maintained thereafter) or continuously regenerated. Most teams should pick frozen, and the generated code should be treated as a starting point you now own — which, conveniently, is also the right mental model for the bundle itself.