Base Main Bundle Laravel Package

Getting Started

tpn/base-main-bundle is an internal Symfony bundle from the TPN/"yourvine" platform. With no stars, no dependents and no Packagist traction, treat it as a read-the-source dependency, not a documented library — the README (if present) is thin and the real contract lives in composer.json, DependencyInjection/, and Resources/config/.

Minimal path:

1. Confirm the Symfony generation first. The Bundle suffix in the name strongly implies a Symfony 2.x/3.x-era bundle (AppKernel::registerBundles()), not a Symfony 4+/5+ flex recipe. Read composer.json for symfony/symfony or symfony/framework-bundle constraints before anything else — this single file tells you whether you're dealing with AppKernel, bundles.php, or a hard incompatibility.
2. Install. If it isn't resolvable via Packagist, add it as a VCS repository:

   "repositories": [{ "type": "vcs", "url": "https://github.com/yourvine/TPNBaseMainBundle" }]
   

   then composer require tpn/base-main-bundle:dev-master. Pin to a commit hash, not a branch — nothing here is versioned for consumers.
3. Register it in app/AppKernel.php (new TPN\BaseMainBundle\TPNBaseMainBundle()) or, on Symfony 4+, in config/bundles.php.
4. Look here first, in order: DependencyInjection/TPNBaseMainBundleExtension.php (what services/getParameters are loaded), DependencyInjection/Configuration.php (the config tree — this is the de facto API), Resources/config/services.yml (service IDs and tags), then EventSubscriber/ and EventListener/ (implicit behaviour).
5. First use case: boot the kernel and run bin/console debug:container --tag=kernel.event_subscriber plus debug:router. Because the bundle is almost certainly glue — service wiring, shared base classes, and event subscribers common to the TPN apps — the fastest way to learn its surface is to diff the container before and after registering it.

Implementation Patterns

Treat the bundle as infrastructure, not a feature. The "Base/Main" naming means it establishes conventions the rest of the app inherits. Expect the day-to-day patterns to be:

• Inheritance over injection for base classes. Base controllers, base entities/repositories, or abstract test cases are the typical payload of a *MainBundle. Extend them (class FooController extends BaseController) rather than reimplementing; the value is consistency across the TPN apps, not functionality.
• Config-tree-driven behaviour. Whatever appears in Configuration.php is the supported customisation surface. Put your overrides in app/config/config.yml under the bundle's root key and resist editing the bundle in vendor/ — the moment you patch vendor/, composer update becomes a hazard.
• Service overrides via compiler pass. To swap a bundled service, prefer a small CompilerPass in your own bundle ($container->setDefinition($id, $newDef)) or an alias in services.yml over class-editing. This keeps the fork upstream-mergeable.
• Event subscribers as the integration seam. If the bundle registers subscribers on kernel.request / kernel.response, that's how it injects cross-cutting behaviour. Hook your own logic onto the same events after it (lower priority number runs later) rather than duplicating its work.
• Fork-and-vendor when you need behaviour changes. Given zero dependents, upstream is effectively frozen. Fork to yourorg/tpn-base-main-bundle, point the VCS repository at your fork, and keep a CHANGELOG of local patches so you can rebase if upstream ever moves.

Gotchas and Tips

• Abandonment risk is the headline risk. Zero stars/dependents means no security review, no Symfony-version bumps, and no issue triage. Audit composer.json for symfony/* constraints and transitive deps before shipping; you are the maintainer now.
• Bundle-suffix era incompatibility. If it targets Symfony ≤3.4, it cannot be dropped into a Symfony 5/6/7 app as-is: AppKernel is gone, Bundle classes are deprecated (removed in 5.0), and templating/Resources/views conventions changed. Migration means converting the bundle to a plain Composer library with a services.yaml — usually cheaper than fighting it.
• Autoload mismatch. Old bundles frequently use PSR-0 (TPN\BaseMainBundle\ → src/TPN/BaseMainBundle/) while modern tooling assumes PSR-4. Check autoload in composer.json; a namespace that "exists" but won't resolve is almost always this.
• Config caching masks YAML edits. After touching config.yml or the bundle's extension, bin/console cache:clear --env=prod — otherwise you'll debug a config change that never loaded.
• getParameter() values are strings. Classic Symfony gotcha that bites hardest in base bundles: %some.flag% arrives as "false"/"0", and if (%some.flag%) is truthy for "false". Coerce explicitly.
• Debugging entry points: debug:container --show-private, debug:event-dispatcher <event>, and debug:config <alias> (Symfony 3.3+) to inspect the resolved tree. If debug:config shows nothing, the extension isn't loading — check the alias in getAlias() matches your YAML root key.
• Extension points to preserve when forking: the Configuration tree (add nodes, don't rename), the getAlias() value, and service IDs (other TPN bundles may hardcode them). Renaming any of these three cascades into breakage.
• Don't rely on the test suite. If tests exist at all, they'll be pinned to era-appropriate PHPUnit and PHP versions (likely 5.6/7.1). Read them as documentation of intended behaviour, not as a runnable safety net.