Base Bundle Laravel Package

Getting Started

vincet/base-bundle is a Symfony bundle by Vincent Touzet that was extracted as a shared foundation for his other bundles (the vincet/* family). Treat it as an internal utility library rather than a standalone framework: at 1 star, zero dependents, and a final release in October 2016, you should assume the documentation lives in the code, not in a README.

First steps:

1. Confirm it installs on a modern Symfony. Run composer require vincet/base-bundle in a scratch project and read the solver output. The bundle predates Symfony 3.3's autowiring-by-default and Symfony 4's Flex recipe system, so expect to register it manually in app/AppKernel.php (or config/bundles.php on 4+).
2. Read the source in this order: composer.json (to see the symfony/* constraints and the autoload namespace), then DependencyInjection/, then Resources/config/services.yml (or .xml). That tells you what services it registers and under which IDs.
3. Look at the author's sibling bundles (vincet/* on Packagist). BaseBundle exists to be consumed by them, so a sibling's composer.json and service definitions are the de facto usage examples.
4. First use case: pull a single base class (e.g. an abstract entity, repository, or controller) into one model/controller and run the test suite. If the class depends on a container service that was renamed or removed in your Symfony version, you'll find out immediately rather than after wiring it everywhere.

If composer require fails on your Symfony version, stop — do not patch it in-tree unless you're prepared to own the fork.

Implementation Patterns

Because the bundle is small and unmaintained, the realistic patterns are "cherry-pick" rather than "adopt wholesale."

Pattern 1 — Inherit the base classes. The typical use is extending whatever abstract classes the bundle ships (base entity/repository/controller). Register the bundle in the kernel, let its service definitions load, then have your own classes extend the provided ones. Keep your overrides shallow: if you find yourself overriding more than one method, the base class is probably wrong for your case.

Pattern 2 — Consume the registered services. After registration, inspect the container (bin/console debug:container --show-private | grep vincet) to see the service IDs. Inject them by ID into your own services rather than reaching into the container. On Symfony 4+, you'll likely need to add explicit services: aliases because the bundle's YAML predates autowiring conventions.

Pattern 3 — Copy, don't depend. For a bundle this size and this stale, the strongest day-to-day pattern is to copy the handful of classes you need into your App\ namespace, keep the MIT license header, and drop the Composer dependency. You get the utility without pinning a 2016 package into your dependency graph and without inheriting its Symfony version constraints. This is usually the right call in 2024+.

Pattern 4 — Treat it as a compatibility shim. If another vincet/* bundle you actually want requires this one, install it only as a transitive dependency, let Composer resolve it, and never reference its classes directly in your own code. That way, if you later swap the parent bundle out, nothing breaks.

Integration tip: pin an exact version in composer.json ("vincet/base-bundle": "1.0.0" rather than ^1.0) so a surprise tag can't shift behavior under you — though given the release date, no new tags are coming.

Gotchas and Tips

• It is abandoned in all but name. No release since 2016-10-25, no dependents on Packagist, one star. There will be no security patches, no Symfony 5/6/7 compatibility work, and no issue triage. Treat every use as a fork you now maintain.
• Symfony version drift is the main failure mode. Expect deprecations from removed container APIs (get(), ContainerAware, ContainerAwareInterface), the old Resources/config/services.yml layout, and services definitions without public: false. On Symfony 4+, run bin/console lint:container and check the deprecation log after boot.
• Service definition quirks. Pre-Flex bundles often declare services with explicit class: and arguments: pointing at concrete implementations. If a class was renamed upstream, the container compiles fine but fails at first resolution — boot the app and touch each service to smoke-test.
• Namespace discovery. The autoload block in composer.json is authoritative; the bundle name (vincet/base-bundle) does not necessarily match the PHP namespace (Vincet\BaseBundle or similar). Confirm before writing use statements, or you'll chase "class not found" errors.
• No test suite you can trust. Any tests in the repo were written against PHP 5.6/7.0-era Symfony. Don't run them as a green light; write your own smoke test that boots the kernel with the bundle enabled.
• Debugging recipe: bin/console debug:container --tag=kernel.event_subscriber, debug:router, and debug:event-dispatcher after registration will reveal what the bundle actually contributes. If nothing shows up, the bundle registered no services and is just a class library — in which case skip registration entirely and autoload the classes.
• Extension points are thin. If the bundle exposes a Configuration class with a tree, read it (DependencyInjection/Configuration.php) for the knobs; otherwise there's nothing configurable, and "configuring" it means overriding services in your app config.
• Licensing is fine, maintenance is not. MIT means you can fork, rename, and vendor it freely — do that rather than filing issues into a repo that hasn't seen a commit in nearly a decade.