Getting Started

Reality check first: knplabs/rad-bundle is a Symfony 2 bundle, archived, last tagged in September 2015, and explicitly unmaintained. It has zero dependents and no Laravel integration path — there is no service provider, no facade, no Composer constraint that will resolve cleanly against a modern Laravel app. You cannot composer require this into a Laravel project and expect it to boot. So "getting started" for a Laravel developer means one of two things:

If you must run it: stand up a throwaway Symfony 2.8 sandbox (PHP 5.6/7.0 era), require knplabs/rad-bundle at its last release, register Knp\Bundle\RadBundle\KnpRadBundle in AppKernel, and follow the bundle's app/-centric layout. Treat it as a museum piece — no production use, no security patches.
The realistic path: don't install it. Read its source on GitHub as a design document for RAD conventions, then map the ideas onto Laravel primitives you already have.

Where to look first (as a Laravel dev):

README.md for the feature list — it reads like a checklist of what Laravel already gives you (generators, convention-over-configuration, annotation routing).
The generator commands (Command/ directory) — this is the closest analogue to php artisan make:*, and the most directly portable idea.
The DependencyInjection/ and Configuration.php files — useful as a reference for how bundles expose config trees; compare with Laravel's config/*.php + mergeConfigFrom.
AppKernel / app-directory conventions — compare against bootstrap/app.php and Laravel 11's slim skeleton.

First use case (ported): replace a repetitive "create model + form + controller + route" workflow in Laravel with a single artisan make:feature command. That's the actual value you can extract from this bundle in 2024.

Implementation Patterns

Since direct integration is off the table, the practical patterns are translation patterns — how the RAD ideas in this bundle map onto Laravel.

1. Generators → Artisan commands

RadBundle's headline feature was opinionated scaffolding. The Laravel equivalent is a custom generator command:

// app/Console/Commands/MakeFeatureCommand.php
class MakeFeatureCommand extends GeneratorCommand
{
    protected $signature = 'make:feature {name}';
    protected $type = 'Feature';

    protected function getStub() { return base_path('stubs/feature.stub'); }

    protected function getDefaultNamespace($rootNamespace)
    {
        return $rootNamespace.'\Features';
    }
}

Stub out model + migration + form request + controller + resource route in one go; that is the RadBundle philosophy applied.

2. Auto form guessing → Form Requests + validation rules

RadBundle guessed form types from entities/validation metadata. Laravel's native answer is FormRequest with rules(), plus Rule:: objects. If you want to go further, derive rules from a schema:

// app/Support/RulesFromSchema.php
public static function for(string $table): array
{
    return collect(Schema::getColumns($table))
        ->mapWithKeys(fn ($c) => [$c['name'] => $c['nullable'] ? ['nullable'] : ['required']])
        ->all();
}

That's the "guess the form from the model" idea, expressed idiomatically.

3. Annotation routing → Route attributes

RadBundle leaned on annotation-based routing. Laravel 11's Route::controller(...) and PHP-attribute patterns give you the same ergonomics — the equivalent file is routes/web.php plus Route::resource.

4. "App-centric" layout → Domain/Feature folders

The bundle's simplification of Symfony's app/ folder is conceptually the same move as Laravel's app/Features/* or app/Domain/* structure. If you like RadBundle's "everything for a feature lives together," that's the pattern to copy.

5. Service auto-wiring

Symfony's container auto-wiring mirrors Laravel's container resolution. If you're porting RadBundle-style controllers, keep them constructor-injected and rely on Laravel's binding rather than facades — it's the pattern the bundle was designed around.

Integration tips

Do not add knplabs/rad-bundle to a Laravel composer.json. It pulls in Symfony 2 components that conflict with Laravel's Symfony 7 deps.
If you want the ideas with maintained code, look at symfony/maker-bundle (the direct successor in spirit) and Laravel's own artisan make:*.
If you're maintaining a legacy Symfony 2 app that already uses RadBundle, the migration targets are symfony/maker-bundle, sensio/framework-extra-bundle for annotations, and Symfony Flex recipes for structure.

Gotchas and Tips

Pitfalls

It will not install on Laravel. The package's Symfony version constraints (~2.x) are incompatible with modern Laravel (Symfony 6/7). Composer will either refuse to resolve or pull a decade-old dependency tree.
No security maintenance. Archived since 2015. Any pattern you copy is fine; any code you run is not.
PHP version ceiling. The last release targets PHP 5.x/early 7.x. It will not run on PHP 8.2+, which Laravel 10/11 require.
Zero dependents is a signal, not a stat to hand-wave. Nobody is maintaining integration paths, so any blog post or Stack Overflow answer you find will be stale.
Do not confuse it with KnpLabs' maintained bundles. knplabs/knp-paginator-bundle, knplabs/knp-menu, knplabs/knp-snappy are still alive; rad-bundle is not.

Debugging (if you're actually in a legacy Symfony 2 app)

If bundle registration fails, the issue is almost always the AppKernel::registerBundles() entry or the app/config/config.yml import ordering — RadBundle expected a specific load order.
Generator failures are usually stale caches; clear app/cache before rerunning.
When annotation routing silently breaks, check that sensio/framework-extra-bundle is registered before RadBundle.

Tips and extension points (for porting)

Mine the generators, not the runtime. The Command/ classes are the most valuable part; they show what a 2015-era team considered boilerplate, and that list is still roughly accurate today.
Compare config shapes. RadBundle's Configuration.php tree is a good example of how to design a bundle/package config — useful if you're writing a Laravel package and want a clean config/yourpackage.php contract.
Don't port the app-directory convention literally. Laravel 11 already has a slim skeleton; forcing a Symfony-style layout into it creates friction with artisan and package discovery.
If you're modernizing a legacy RadBundle app, the migration order is: kernel → console → routing → generators → forms, and stop at "generators" if you're on a timeline — that's where 80% of the team-velocity win lived.
Extension points worth borrowing: the "convention + a config escape hatch" pattern in DependencyInjection/Configuration.php is a clean way to expose opinions without locking users out. It's the same philosophy Laravel uses for config/app.php defaults.

Rad Bundle Laravel Package