Framework Extra Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — a critical distinction before you invest any time. There is no ServiceProvider, no config/toa.php, no facade, and no Laravel auto-discovery entry. composer require will pull it in, but php artisan will never touch it. If you are evaluating this for a Laravel app, the honest answer is that you cannot use it directly; you would need to be running Symfony's HTTP kernel alongside or inside Laravel for the bundle's extension points to mean anything.

Assuming you are actually on Symfony (the only context where this makes sense):

1. Read composer.json first. Check the symfony/* version constraints and the type. A bundle this small (1 star, 0 dependents) is frequently pinned to an old Symfony major, which will block installation on any modern app before you even see code.
2. Check the namespace root in composer.json (autoload.psr-4) and confirm it does not collide with Sensio\Bundle\FrameworkExtraBundle. The name is deliberately close to the well-known sensio/framework-extra-bundle; verify this is a distinct fork/rewrite and not a namespace shadow that will fight with an existing install.
3. Skim src/ for a *Bundle class and a DependencyInjection/*Extension. Those two files tell you almost everything: what services get registered, what configuration tree (if any) exists, and whether there are compiler passes.
4. First use case is almost certainly annotation/attribute-driven controller configuration (routing, param conversion, security, cache, template defaults) — the same surface Sensio's bundle covers. Try the smallest thing the README shows on a single throwaway controller before touching an existing app.

Realistically: budget 30 minutes to determine whether it installs at all. With this dependency profile, the expected outcome is that you either vendor the two or three classes you actually need into your own src/, or you reach for sensio/framework-extra-bundle (still maintained by the Symfony org) instead.

Implementation Patterns

The patterns below are the generic ones any *ExtraBundle of this shape follows; confirm each against the actual source before relying on it.

Registration and configuration. Register the bundle in config/bundles.php (Symfony 4+) or AppKernel::registerBundles(). If an Extension class exists, its alias is derived from the bundle name — check Configuration.php for the root node name, since a mis-named alias is the single most common reason config silently does nothing.

Service wiring. Look for Resources/config/services.xml / .yaml and any CompilerPass. Annotations are read at container-compile time by event subscribers tagged kernel.event_subscriber (typically on kernel.controller). If those tags are missing from the service definition, the bundle loads cleanly and does absolutely nothing — a failure mode with no error message.

Attribute/annotation usage. If the bundle is Symfony 6+ compatible, expect PHP 8 attributes (#[Route], #[Cache], etc.) rather than doctrine annotations; if it targets 4.x/5.x, expect @Route-style and you will need doctrine/annotations installed and annotation reading enabled on the container.

Fork-and-inline pattern (the one I would actually recommend here). Rather than depending on a 1-star package, copy the listener/subscriber classes you need into src/EventSubscriber/ in your own app, register them as ordinary services, and drop the dependency. You keep the behaviour, gain type-safety and tests, and lose nothing — the bundle's only real job is registration boilerplate.

Laravel-side integration, if you insist. The only sane route is to instantiate the relevant classes manually from a Laravel service provider and translate Symfony's Request/Response objects at the boundary. This is a bridge project in its own right and is almost never worth it for a package of this size; reimplementing the logic with Laravel middleware is faster and clearer.

Gotchas and Tips

• Maintenance risk is the headline. One star, zero dependents, and a package name that mirrors a famously maintained Symfony bundle. Treat every line as unreviewed. Pin the exact version, commit composer.lock, and assume no upstream fixes will arrive.
• Namespace collision with Sensio. Both bundles conceptually occupy the FrameworkExtraBundle space. Having both installed can produce duplicate event subscribers — double route registration, double param conversion, or a hard container error on conflicting service IDs. Check debug:container for duplicate tags.
• Silent no-ops. If annotations aren't parsed, or the subscriber isn't tagged, nothing throws — your routes just don't appear or your @Cache is ignored. Debug with bin/console debug:router and debug:event-dispatcher kernel.controller rather than guessing.
• Annotation cache. On Symfony 4/5 with doctrine/annotations, stale var/cache will hide changes to annotations. cache:clear before concluding the bundle is broken.
• Version constraints block installs quietly. If composer require resolves to something ancient or refuses outright, check the symfony/http-kernel and php constraints in composer.json — that's the usual culprit, not your app.
• Extension point to prefer: the kernel.controller listener pattern. If you do fork it, that's the seam to keep; everything else in the bundle is likely glue you can drop.
• Write one regression test around whatever behaviour you adopt (e.g. "route attribute produces a route"). With no upstream test suite you can trust, your test is the spec — and it's the only thing that will catch a future Symfony upgrade breaking the copied code.