Framework Extra Bundle Laravel Package

Getting Started

First, calibrate expectations: this is a Symfony bundle, not a Laravel package. It does not ship a ServiceProvider, does not support package auto-discovery, and cannot be composer required into a Laravel app and "just work." Stars (5) and archived: yes tell you the real story: this is a reference/legacy codebase, not a dependency. Treat it as source material to read and copy from, not something to install.

Minimal steps for a Laravel developer:

1. Read, don't install. Clone the repo and read composer.json first — the require block tells you which Symfony versions it targets, and therefore which PHP features and API shapes you're looking at. An archived bundle is almost certainly pinned to Symfony 3/4-era conventions.
2. Map the file layout before reading classes. Look in this order:
   • DependencyInjection/ — the *Extension class and Configuration.php (this is the authoritative list of config knobs).
   • Resources/config/ — services.xml/services.yaml, where the actual object graph lives.
   • src/ (or the PSR-4 root) — the "extra classes": typically base controllers, base repositories/entity managers, form types, or traits.
   • Tests/ — the best documentation of intended behavior.
3. Identify the one thing worth stealing. Small bundles like this usually exist to remove boilerplate in a handful of places. Find the base class or trait that saves the most lines and port that concept, not the bundle.
4. First use case (Laravel): port a base class into app/Support/. For example, a Symfony Controller subclass with convenience helpers becomes an app/Http/Controllers/BaseController.php; an EntityRepository base becomes a app/Repositories/BaseRepository.php wrapping Eloquent; Symfony AbstractType form classes become FormRequest + a Form/DTO mapper. Copy the shape, replace the framework calls.

If you genuinely are in a Symfony app and want to use it as-is: register it in config/bundles.php, then inspect bin/console debug:config <alias> to see the merged configuration tree.

Implementation Patterns

Pattern 1 — Fork-and-vendor (recommended). Do not add an archived dependency. Copy the specific classes you want into your own namespace, strip the Symfony-only imports, and write tests around the behavior you actually rely on. Attribution is cheap; supply-chain risk from an unmaintained bundle is not.

Pattern 2 — Concept translation to Laravel. The recurring idioms in bundles of this type map cleanly:

Pattern 3 — Convention layer. If you lift the base classes wholesale, adopt their conventions consistently (naming, protected helper methods, return types). The value of a bundle like this is uniformity; a half-adopted convention layer is worse than none.

Pattern 4 — If using it in Symfony for real. Extend the provided base classes rather than composing around them, override only what the extension explicitly documents, and lean on the bundle's own Tests/ as an executable spec for edge cases. Keep a thin local subclass layer (App\Controller\BaseController extends Majora\Controller\...) so a future replacement is a one-file change.

Pattern 5 — Integration via decoration, not modification. Where the bundle registers services, prefer Symfony's service decoration or a compiler pass in your bundle over editing vendor code. On the Laravel side, the analogue is $app->extend() / $app->bind() with a subclass.

Gotchas and Tips

• Archived means frozen. No security fixes, no PHP 8.3/8.4 compatibility work, no Symfony 6/7 support. Before anything else, diff the composer.json constraints against your runtime. Composer will happily resolve old constraints and leave you on an unsupported stack.
• It is not Laravel-compatible by design. There is no Laravel\...\ServiceProvider, no extra.laravel block in composer.json, no auto-discovery. Any attempt to composer require it into a Laravel app produces a package that is simply never loaded.
• Config key naming is derived, not declared. Symfony derives the config alias from the extension's naming convention, which is often not the vendor/package name. Always run bin/console debug:config <alias> rather than guessing the YAML root key. The Configuration.php tree is the ground truth for defaults.
• Extension load() ordering matters. If configuration values appear ignored, the issue is usually that services are defined in Resources/config/ before the extension has pushed parameters in — or the parameter name changed between versions.
• Debugging checklist (Symfony): debug:container --show-private to confirm services exist, debug:config for merged config, debug:router for anything route-related, then cache:clear — a stale container is the #1 cause of "my override does nothing."
• Debugging checklist (Laravel port): after copying classes, immediately add declare(strict_types=1) and convert Symfony exceptions (NotFoundHttpException, AccessDeniedHttpException) to Laravel ones, or you'll get confusing 500s from code that "worked" in Symfony.
• Extension points, if you must use it in Symfony: service decoration, compiler passes in your own bundle, and template overrides via Resources/views naming conventions. Do not patch vendor/ — with an archived package there is no upstream to send fixes to and no release to re-pull.
• Low dependents (0) is a signal. There's no community pressure testing it, no Stack Overflow corpus, no ecosystem of plugins. Budget time to read the source end to end; it's small enough that this is genuinely faster than searching.
• Opportunity framing: at 5 stars and 0 dependents, the realistic value here is as a cheap source of boilerplate ideas — 30 minutes of reading to shortcut a base-class design decision. It is not infrastructure.