Framework Bundle Laravel Package

Getting Started

Read the deprecation banner before anything else. The package description literally reads [DEPRECATED] use symfony/framework-bundle instead. That upstream instruction is the entire onboarding: there is no greenfield adoption path, and there is no Laravel integration path. Everything below is written for the only realistic situation a Laravel developer will hit this package — finding it in an inherited composer.json or a transitive dependency during a framework-upgrade audit.

Confirm what you're actually looking at. This is a Symfony bundle (Composer type symfony-bundle), not a Laravel package. It wires into Symfony's AppKernel/bundles.php, its DI container extension, and its Configuration tree — none of which exist in Laravel. There is no ServiceProvider, no facade, no config/*.php publish hook, and nothing to php artisan vendor:publish. If a ticket asks you to "integrate kingfoo/framework-bundle into Laravel," send it back — the premise is wrong.

Minimal audit steps:

composer show kingfoo/framework-bundle      # version, requires, install path
composer why kingfoo/framework-bundle       # who actually pulls it in
composer depends kingfoo/framework-bundle   # reverse deps (expect empty)

Where to look first, in order:

1. README.md / CHANGELOG.md — the deprecation notice and last-supported Symfony/PHP versions.
2. The bundle class, typically src/*Bundle.php (e.g. KingFooFrameworkBundle.php) — check getContainerExtension(), build(), boot().
3. src/DependencyInjection/*Extension.php and *Configuration.php — the config tree, defaults, and service IDs it registers. This is where the real behaviour lives. Most of these "framework bundles" are just a handful of service definitions plus sensible defaults.
4. src/Resources/config/*.{yml,xml,php} — the actual service definitions.

First use case — the only one that matters: open config/bundles.php (Symfony 4+) or app/AppKernel.php (Symfony 2/3) in the legacy app, find the registration line, and prove what breaks if you delete it. In almost every case, removal is a mechanical exercise: inline the bundle's default parameter/service definitions into your app's own config/services.yaml and config/packages/*.yaml, then drop the dependency.

Implementation Patterns

Pattern 1 — Legacy Symfony registration (keep-alive, not adoption). If you're forced to keep it running in a Symfony 2/3/4 app while migration is scheduled:

// Symfony 4+: config/bundles.php
return [
    // ...
    KingFoo\FrameworkBundle\KingFooFrameworkBundle::class => ['all' => true],
];

// Symfony 2/3: app/AppKernel.php
$bundles = [
    new KingFoo\FrameworkBundle\KingFooFrameworkBundle(),
];

Configuration goes under the extension alias — confirm it from Extension::getAlias() rather than guessing:

# config/packages/king_foo_framework.yaml (alias = whatever getAlias() returns)
king_foo_framework:
    # keys mirrored from Configuration::getConfigTreeBuilder()

Pattern 2 — Migration by inlining. This is the pattern you actually ship. The bundle's value is its defaults, so extract them:

1. Read *Extension::load() — it will call $container->setParameter() and $loader->load('services.xml') (or yml/php).
2. Copy those parameter defaults into a config file in the host app.
3. Copy the service definitions verbatim into your app's own service config, renaming keys if the bundle's alias collided with yours.
4. Remove the bundle registration line and the composer.json entry in the same PR.

This is a one-PR change in most cases; do not stage it across sprints.

Pattern 3 — Laravel-side equivalents (what to reach for instead). The capabilities the README advertises map cleanly onto Laravel primitives, which is why the Laravel answer is "use the framework":

If a team has already started wiring the bundle into a Laravel branch, the migration is backwards: remove the dependency first, then re-derive the actual requirement against the table above. There is no forward port from a Symfony bundle to Laravel's container.

Pattern 4 — Dependency-hygiene gate. Add it to your dependency-review checklist as a known-deprecated entry so the next PR that tries to add it fails review rather than passing silently. Pair that with a composer audit step in CI so any transitive Symfony-era CVE gets flagged once the package is finally removed.

Gotchas and Tips

The silent-inertness trap. Dropping a Symfony bundle into a Laravel app "succeeds" at the Composer level and then does nothing — the bundle class is autoloaded but never registered, no extension runs, no services are bound. You end up with a green build, a feature that looks configured, and a runtime BindingResolutionException the first time someone actually needs the service. If you see kingfoo/framework-bundle in a Laravel composer.lock, treat that as evidence the wiring is dead code, not as evidence it works.

Composer resolution is the real blast radius. The bundle's Symfony component constraints are 2016-era. On any modern tree, composer require or composer update will either fail resolution outright or — worse — succeed by downgrading symfony/* across the whole graph. Always check composer why and composer outdated before removing the package, because the removal may need to happen in the same commit as the Symfony upgrade (it is not an independent cleanup).

Framework mismatch is not a "spike" question. There's no bridging layer to write, no adapter to test. Laravel's Illuminate\Container and Symfony's DependencyInjection are different contracts. Any "let's just make it work" ticket is really a ticket to reimplement the bundle inside Laravel, at which point you are forking an abandoned package to reproduce what Laravel already ships. Kill it in review.

Config keys are not what you expect. If you are looking at a legacy Symfony app, do not guess the yaml alias or the parameter names — pull them from Extension::getAlias() and Configuration::getConfigTreeBuilder(). These bundles frequently use an underscored alias (king_foo_framework) that does not match the namespace (KingFoo\FrameworkBundle), and mis-typing it fails silently (config is ignored, defaults apply) rather than throwing.

Extension points, and why you should not use them. The description advertises "clear extension points for custom behaviour" — realistically this means subclassing the Extension or overriding the bundle's build(). Do not. Every extension you write against this bundle is code you'll rewrite during the migration, and the maintainers have already told you the successor is symfony/framework-bundle, which has its own (maintained) extension contract.

No security patch path. When a CVE lands in one of its transitive Symfony deps, you cannot ship a fix within the pinned constraints. If you have to leave the bundle in a legacy app for a release cycle, document the residual risk explicitly and set a removal deadline in the ticket — "we'll get to it" is exactly how these dependencies survive for another three years.

Do not re-export or wrap it. A tempting "safe" move is to write a thin internal wrapper so other teams depend on your package rather than the deprecated one. Don't — it multiplies the exit cost and adds a second unmaintained surface. If the underlying capability is genuinely needed, port the tiny amount of actual behaviour (usually: a few container parameters and one or two service bindings — see Pattern 2) directly into the host application and delete the dependency.

Verification after removal. After dropping the line in bundles.php/AppKernel.php and composer remove kingfoo/framework-bundle, run the container compile (bin/console cache:clear && bin/console debug:container in Symfony, or php artisan about in Laravel) — the bundle's job was usually just setting a couple of parameters, so a container compile is the fastest way to catch anything that referenced them.