Symfony Static Di Bundle Laravel Package

Technical Evaluation

Scope correction first: this is a Symfony bundle, not a Laravel package. The name, Bundle suffix, and repo layout all point to a Symfony container-level integration. Laravel's DI is a runtime, reflection-driven container with no compile phase; static container generation does not port to it. If the estate in question is Laravel, the assessment ends at "not applicable." Everything below assumes a Symfony service in scope.

Architecture fit. Static DI operates at the container compilation phase — the highest-blast-radius point in a Symfony application. A bundle registers a compiler pass and an extension, which means it can affect every service definition, every test kernel boot, and every cache warmup. Failures are systemic, not local. That is acceptable only when the package is small, understood, and owned.

Integration feasibility. With 0 stars and 0 dependents there is no adoption evidence to lean on, so feasibility rests entirely on reading the source. The shape (a bundle) makes the spike cheap: composer require in a branch, cache:clear, boot the kernel, run the suite. The real question is not "can we install it" but "does it produce a measurable win over the stock PhpDumper output."

Technical risk. Bus factor of one, no external consumers, unknown CI matrix across Symfony minors, uncertain semver discipline. Static DI implementations couple tightly to internals — ContainerBuilder, PhpDumper, CompilerPassInterface, tagged iterators, service locators, synthetic services, env-var placeholders. Symfony perturbs these regularly. Concrete risks: services missing at runtime, decoration order changing, lazy/proxy services breaking, and silent divergence between the generated static container and the real compiled container. The dangerous failures are not build errors; they are runtime misses.

Key questions to put to the maintainer (or answer from source):

• What problem is actually being solved — static-analysis friendliness (PHPStan/Psalm seeing concrete types), faster container compilation, or a runtime-free/preloadable container? These have very different value.
• Supported Symfony version matrix and PHP floor?
• Is the static container generated at build time and committed, or at deploy time? How is staleness detected?
• Does it survive the full test boot path (KernelTestCase, WebTestCase, functional tests with cache warmup)?
• Support for compiler passes, decoration, service locators, tagged iterators, parameters, env placeholders, lazy services?
• Can it be removed cleanly if abandoned, without touching application code?
• Is there a test suite that diffs the static container against the reference container?

Integration Approach

Stack fit. Symfony only. If the fleet is predominantly Laravel, treat this as out of scope and archive the evaluation. If there is a Symfony component and the driver is either static-analysis quality or container compile time on a genuinely large app, a timeboxed spike is justified.

Migration path. Non-destructive by construction: add as a dev requirement, enable on a branch, run the full suite plus a container-diff. Production adoption means pinning to an exact commit and treating it as a vendored dependency, not consuming it from upstream floating.

Compatibility. Pin to the exact Symfony minor in use; do not assume a support window. Pay particular attention to interaction with framework-bundle, security-bundle, doctrine-bundle, and messenger — security and messenger lean heavily on compiler passes, tagging, and service locators, which is precisely where static container generation tends to break. Also verify that the static-analysis toolchain actually benefits; a static container introduced to help PHPStan is worthless if the analyzer still can't resolve the generated types.

Sequencing.

1. Read the source — it is small. Document the compiler pass and exactly what it emits.
2. Timeboxed spike on one non-critical Symfony app. Measure container compile time and test-suite runtime before and after.
3. Build a parity harness: dump the service graph with and without the bundle, diff. Any missing or reordered service is a stop signal.
4. Only if there is a measurable win: fork, add a CI matrix across supported Symfony minors, vendor it internally.
5. Pilot in one non-critical app for a full release cycle before anything else is considered.

Operational Impact

Maintenance. Assume zero upstream maintenance. With 0 stars and 0 dependents, adopting this means owning it. MIT permits a fork, but the fork commits the team to absorbing every Symfony minor upgrade indefinitely. Budget that as a recurring cost per Symfony major, not a one-time setup.

Support. No community, no issue triage history to read, no Stack Overflow surface. Escalation is "read the source." Acceptable only for a component small enough that one engineer can hold it in their head.

Scaling. The benefit, if it exists, scales with application size — this is a tool for large, container-heavy apps. So does the fragility: more bundles and compiler passes mean more surface for divergence. For a small or mid-size app the calculation is straightforwardly negative.

Failure modes. The silent ones are the concern. Missing services, altered decoration order, and stale generated containers tend to surface as confusing runtime errors after deploy rather than clean build failures. A parity check in CI is mandatory, not optional; without it this becomes a debugging tax on every post-deploy incident.

Ramp-up. Requires a senior engineer fluent in Symfony DI internals: compiler passes, PhpDumper, tagged iterators, service locators, cache warmup semantics. That is a narrow skill set. Estimate one experienced Symfony developer for roughly a week to evaluate properly, and that same person as the permanent owner. Do not assign this to someone learning the container model while debugging it.

Bottom line. Evaluation cost is low; adoption ceiling is low (opportunity score 15.39 reflects that) unless it resolves a specific, measured pain; ownership cost is real and permanent. Treat this as a research spike with a hard stop criterion, not a procurement decision.