Service Factory Bundle Laravel Package

Product Decisions This Supports

• Framework-fit gating before any evaluation spend: the package is billed as a "Laravel/PHP package," but it is a Symfony bundle (Bundle class, config/bundles.php registration, compiler-pass DI). The first product decision it informs is a portfolio one: confirm which of our products actually run Symfony before allocating engineering time. For a Laravel-first portfolio, the correct outcome is "no decision required — out of scope."
• Build vs. buy on developer-experience tooling: the package reduces repetitive DI boilerplate by auto-injecting services into factory classes instead of requiring manual service tagging. The PM decision is whether to standardize a factory-injection pattern at all, and if so, whether to own it internally or take a third-party dependency. Given zero stars, zero dependents, and a single-vendor origin, the buy-side case is weak; the build-side case is a small internal helper or a refactor onto native Symfony features (ServiceSubscriberInterface, !tagged_locator, #[AutowireLocator]).
• Roadmap input for a platform/DX initiative: the opportunity score (49.3) against a quality signal of 0.2 is the useful signal here — it indicates demand for reduced DI boilerplate, not readiness of this package. Log it as evidence for a developer-experience workstream (container conventions, factory patterns, onboarding docs), not as a dependency request.
• Risk and maintenance budgeting: adopting this adds a dependency with no community triage, no upgrade guarantees, and no peer usage to learn from — directly increasing support burden, security-review scope, and bus-factor exposure. That trade-off should be priced explicitly against the hours saved.
• Use-case qualification: legitimate only for large Symfony monoliths with many factory classes and recurring tag registration. Low to zero value for small services, Laravel applications, or teams already using Symfony autoconfiguration and compiler-pass conventions.

When to Consider This Package

Consider it only if all of the following hold:

• The target codebase is Symfony, not Laravel and not framework-agnostic PHP.
• You have a measured, recurring pain point: factory services that require manual tag registration and per-class wiring.
• You are willing to treat it as a reference implementation or bounded pilot — read the compiler pass, borrow the pattern — rather than shipping it as a production dependency.
• You can fork or vendor it. The MIT license and small surface area make that legally and technically cheap; the absence of a maintainer makes it effectively mandatory.
• The change can be isolated behind an internal interface (e.g., ServiceFactoryInterface) so the bundle is swappable, and it can be validated with a kernel-boot smoke test in CI.

Look elsewhere (or close the item) if:

• The stack is Laravel — the container, service providers, and contextual binding solve this differently; there is no transferable value.
• Native Symfony mechanisms already cover your factories; they are first-party, supported, and carry no adoption risk.
• You need a dependency with a security response path, an upgrade guarantee, or an SBOM-friendly provenance story.
• The boilerplate turns out to be small. A quick measurement usually shows the internal implementation is hours of work — cheaper than the vendor-review cost of adding a dependency.
• The org requires a supported vendor or a named upstream maintainer for any new transitive dependency.

How to Pitch It (Stakeholders)

For executives (one minute): This is a small, MIT-licensed Symfony utility that removes repetitive service-registration boilerplate when defining factory classes. It is technically narrow and effectively unproven — no community adoption, no dependents, no visible maintenance signal — and it is a Symfony bundle, so it does not apply to our Laravel work at all. Recommendation: do not adopt as a dependency. Treat it as evidence of a genuine developer-experience gap in our Symfony services, and only act on it if we can quantify the boilerplate cost.

For engineering leadership: The value proposition is developer ergonomics, not capability — it automates something standard Symfony container features already do. The risk profile is a solo-maintainer, zero-traction package: no security response path, no upgrade guarantee, no peer usage to learn from, and compiler-pass internals are the most brittle part of Symfony across major versions. If the pattern is genuinely useful, we should read the implementation, adapt it internally, and own it — that captures the DX win with none of the supply-chain exposure, and it is likely cheaper than the vendor-review cost of taking the dependency.

Ask: approve a short spike — half a day to a day — to (a) confirm which of our products are Symfony-based, and (b) measure how much factory-tagging boilerplate we actually carry. If the number is material, we implement the pattern in-house against our own Symfony/PHP matrix; if it is not, we close the item, record the DX signal in the roadmap backlog, and move on.