Bridge Phpdi Symfony Laravel Package

Product Decisions This Supports

• Container-strategy consolidation (build vs. buy vs. keep two): lets a team keep existing PHP-DI definition files as the source of truth for object wiring while running on a standard Symfony kernel — no kernel override, no forked container. This is the "migration without a rewrite" option in the classic buy-vs-migrate decision: adopt the bridge instead of paying for a full DI annotation/autowiring migration.
• Incremental modernization of legacy PHP applications: teams moving a hand-rolled or PHP-DI-based app onto Symfony (FrameworkBundle, HTTP kernel, service tooling) can onboard module by module. PHP-DI entries are exported as Symfony services at compile time, so Symfony-native consumers (controllers, event listeners, compiler passes) can inject them while legacy code keeps its own definitions.
• Roadmap: platform standardization across a mixed estate: if the org has multiple PHP services — some PHP-DI, some Symfony — this is a lever to converge on one runtime (Symfony) without demanding all teams rewrite wiring. Decide "standardize on Symfony DI only" vs. "support a supported PHP-DI compatibility window."
• Feature/architecture decisions on public extension points: the bundle's design (priority-ordered definitions, di_bridge.import aliasing Symfony services into PHP-DI, di_bridge.extensions plugin interface, compile-time export rules) is itself a product surface. A PM cares because these are the knobs that determine how much bespoke glue engineering must build and maintain, and whether third-party bundles can opt in.
• Performance and operational posture decisions: configurable compile-time container export (di_bridge.compilation_path) and optional APCu-backed definitions cache (di_bridge.enable_cache) map directly to cold-start latency, deploy artifact size, and "can this run in a container without APCu" questions — decisions that show up in SLOs and platform baselines.
• Risk and dependency decisions: BSD-3-Clause, PHP 8.4+ requirement, Symfony 6.4.24/7.4/8.1 and php-di/php-di ^7.1.1 constraints, plus a very small community footprint (single lead maintainer), feed into the support-matrix and vendor-risk register rather than into a feature backlog.
• Use cases that justify the capability: strangler-pattern migrations off legacy frameworks; shops with deep PHP-DI investment (large definition sets, env-driven factories) that want Symfony's routing/console/HTTP while preserving wiring; and internal platforms that need a PSR-11 seam between two containers.

When to Consider This Package

Consider adoption when all of the following hold:

• You have a real, non-trivial corpus of PHP-DI definitions you are unwilling or unable to port to Symfony service definitions in the current planning horizon.
• You are standardizing on a stock Symfony kernel — you specifically do not want to maintain a custom Kernel/Container fork (the bridge's main differentiator versus the official Symfony↔PHP-DI integration).
• You need bidirectional container interop: Symfony services resolvable from PHP-DI (via aliasing) and PHP-DI entries injectable into Symfony services (via compile-time export), with Symfony parameters mirrored into the PHP-DI context.
• Your runtime meets the constraints: PHP 8.4+, Symfony 6.4.24+/7.4/8.1, php-di/php-di ^7.1.1. You have CI capacity for the package's test requirements (Xdebug for coverage, APCu for cache tests).
• You can accept vendor risk: 2 GitHub stars, 0 dependents, single primary maintainer. Mitigation: pin the version, keep an internal fork/patched-mirror option, and budget a small maintenance reserve.

Look elsewhere when:

• You are greenfield Symfony. Native Symfony DI (autowiring, tagged services, compiler passes) covers the need; a second container is pure complexity with no migration payoff.
• You are greenfield Laravel or another framework. This is Symfony-specific (symfony/http-kernel, dependency-injection, config) and does not apply; do not treat it as a framework-agnostic PSR-11 utility.
• You need a widely-adopted, commercially supported component. Two stars and no dependents mean no community answers, no third-party tutorials, and no ecosystem of compatible bundles. If organizational policy requires maintained-for-enterprise dependencies, reject on that basis alone.
• You cannot run PHP 8.4. Older releases exist but the maintained line assumes 8.4; back-porting is your cost.
• Your pain is not DI. If the migration blockers are ORM, templating, or session/auth, this package solves a fraction of the problem and creates an extra layer to unwind later.
• You need guaranteed long-term API stability. The di_bridge.* configuration tree and the ExtensionInterface contract are effectively API you would be building on top of an unversioned-by-popularity project.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a body of application code wired with PHP-DI and a strategic direction toward Symfony. The conventional choices are (a) a multi-quarter rewrite of all dependency wiring, or (b) maintaining a private fork of Symfony's kernel. This package offers a third option: a small, BSD-licensed bridge that runs PHP-DI definitions inside a standard Symfony kernel, so we migrate on Symfony's timeline while existing code keeps working. It is low-cost to trial and reversible — no fork, no vendor lock-in at the code level. The trade-off is maturity: the project is essentially single-maintainer with a negligible user base, so the recommendation is a time-boxed pilot with a pinned version and a documented exit path, not an organization-wide standard.

For engineering leadership: The bridge integrates at compile time — PHP-DI entries are exported into the Symfony container as factory-built services, with aliases, priorities, and Symfony parameter propagation handled declaratively via the di_bridge config. It implements PSR-11 for runtime interop and exposes an extension interface for our own conventions. It requires PHP 8.4+, Symfony 6.4.24+/7.4/8.1, and php-di/php-di ^7.1.1; APCu is optional and only needed for the definitions cache.

For the engineering team: Ask for one sprint to validate: (1) boot a real kernel with our largest definition set and measure container compile time and cold-start; (2) confirm our PHP/Symfony versions are inside the supported matrix; (3) assess upgrade exposure to the single maintainer — are we prepared to carry a patched fork? Decision rule: proceed to adoption only if the pilot shows a net reduction in migration effort versus a definition-by-definition port to native Symfony DI, and if we accept ownership of a contingency fork. Otherwise, default to native Symfony DI and treat this bridge as a tactical, time-boxed bridge — which is exactly what its name says it is.