Framework Extra Bundle Laravel Package

Getting Started

First, calibrate expectations: this is a Symfony 2-era bundle, not a Laravel package. If you're coming from Laravel, map the concepts before reading any code:

• Laravel service provider → Symfony bundle + Extension class, registered in AppKernel::registerBundles()
• Laravel config file → DependencyInjection/Configuration.php + config.yml under a bundle alias
• Laravel facades/helpers → plain services or static utility classes

Minimal steps:

1. composer require theodo/framework-extra-bundle (expect to pin a version manually — see Gotchas).
2. Register it: new Theodo\FrameworkExtraBundle\TheodoFrameworkExtraBundle() in app/AppKernel.php (Symfony 2/3 only; there is no bundles.php/Flex recipe).
3. Read the bundle source before trusting the README. At ~3 stars and zero dependents, the src/ directory and any tests are the only reliable documentation — budget 15 minutes to read it end to end.
4. Identify the one or two classes you actually need. The bundle describes itself as "useful classes," which almost always means a grab bag of helpers (controller utilities, annotation helpers, form/entity conveniences) rather than a cohesive feature.

First use case: pick a single utility class, instantiate it directly in a throwaway controller or a php bin/console command, and confirm it behaves as expected on your PHP version. Do not wire it broadly until you've validated autoloading, namespace, and runtime compatibility with your Symfony minor version.

If your target is Laravel or Symfony 4+, stop here — this bundle is not the right tool. For Symfony 4/5+, the equivalent "extra" features live in sensio/framework-extra-bundle (annotations, param converters, template listeners) and Symfony's own FrameworkBundle.

Implementation Patterns

Treat it as a library, not a framework. Because the bundle is a collection of classes rather than an opinionated layer, the cleanest pattern is to consume individual classes as services or static helpers and leave the bundle registration minimal:

// services.yml
services:
    app.your_helper:
        class: AppBundle\Service\YourHelper
        arguments: ['@theodo.some_service'] # only if the bundle exports such a service

If the bundle does not declare services in its DependencyInjection extension, don't invent them — instantiate the classes directly or wrap them in your own service.

Controller-level use. If it ships annotation helpers or base controller traits, use them alongside (not replacing) the standard SensioFrameworkExtraBundle annotations. Keep a single controller as a pilot and diff behaviour against a controller that doesn't use the bundle.

Workflow for evaluating a class safely:

1. Write a tiny PHPUnit test that exercises the class in isolation (tests/Unit/Theodo/...Test.php).
2. If it passes, add an integration test that exercises it inside the container (KernelTestCase).
3. Only then refactor production code to depend on it.

Integration tip: if the bundle's Extension loads config under an alias, inspect what it actually registers via php bin/console container:debug --show-private and grep for the bundle namespace. This is faster than reading Configuration.php.

Migration-friendly usage. Because the package is effectively frozen, wrap any class you depend on behind your own interface. If the upstream code breaks on a PHP upgrade you can swap the implementation without touching call sites.

Gotchas and Tips

• Abandonment risk is the headline. 3 stars, 0 dependents, and a Symfony 2 namespace (Symfony2 in the description) mean it almost certainly predates Symfony 4's bundle conventions. Expect no support, no fixes, and no compatibility with modern Symfony.
• Composer resolution will fight you. There is likely no upper bound or an outdated one on symfony/symfony / symfony/framework-bundle. Expect to add "replace" entries, a minimum-stability override, or a fork.
• PHP version drift. Code from the Symfony 2 era commonly uses patterns that trigger deprecations or fatal errors on PHP 8+ (e.g. each(), dynamic properties, loose type juggling). Run a static analyser (PHPStan level 5+) over vendor/theodo/ before adopting.
• No Flex recipe. There is no config/bundles.php registration and no config/packages/*.yaml — everything is manual AppKernel + app/config/config.yml. If your project is Flex-based, this bundle does not belong in it.
• Overlap with sensio/framework-extra-bundle. Both are "extra" bundles; check for duplicate annotation listeners or route loaders before enabling both. Registering conflicting listeners silently changes routing or param conversion behaviour — the bug surfaces far from the cause.
• Autoloading quirks. Old bundles sometimes ship a composer.json with PSR-0 mappings or a legacy autoload block. Verify with composer dump-autoload -o and a class_exists() smoke test.
• Debugging: if a class "does nothing," check whether it depends on a kernel event that isn't dispatched in your version of Symfony. Use php bin/console debug:event-dispatcher and confirm the bundle's listeners are actually attached.
• Extension point if you must maintain it: fork the repo, raise the symfony/* constraint, add a CI matrix over your PHP/Symfony versions, and tag a fork version. Keep the fork pinned by commit hash rather than branch.
• Verdict for day-to-day use: treat this as a reference implementation to read, not a dependency to ship. The classes themselves are often worth copying into your own AppBundle/Util — which removes the upgrade and supply-chain risk entirely and is almost certainly the better outcome given zero dependents.