Foundry Bundle Laravel Package

Product Decisions This Supports

• Test-tooling standardization. Informs whether the team standardizes on zenstruck/foundry as the factory/fixture layer for Symfony projects, and whether a supplementary bundle is part of that standard stack. This package only matters at the edges of that decision — it is glue, not a capability. Release 0.3.0 does not change that: it renames things, it does not add capability.
• Build vs. buy (and the third option: vendor). The package exists to solve "common problems" wiring Foundry into Symfony components via extra configs and compiler passes. At roughly a few dozen lines of container configuration, this is a build-in-an-afternoon problem, not a buy problem. The 0.3.0 namespace move (icanhazstring\FoundryBundle, bundle class FoundryBundle) is exactly the sort of churn a consumer has to absorb; if we lift the compiler pass into our own test-support bundle, we own the namespace and never do this dance.
• Roadmap: test-suite modernization. Useful as a signal when planning upgrades off Symfony 4.4/5.x and Foundry pre-1.0. Much of what this bundle patched has been absorbed upstream; the roadmap item is "delete the shim," not "adopt the shim." Nothing in 0.3.0 signals renewed upstream alignment — no Symfony version bump, no Foundry 1.x/2.x support statement, no PHP 8.2+/8.3+ compatibility claim.
• Risk register / dependency hygiene. A rename-only release after a long quiet period is a rebrand, not a maintenance signal. It is a breaking change (namespace and class name) shipped inside a 0.x line that nobody depends on — which is precisely why it could be shipped with no migration path. Zero stars, zero dependents, single maintainer, and no security advisory coverage remain the operative facts for a dependency-approval allowlist.
• Use cases it actually addresses. Teams on older Symfony versions hitting container/factory wiring friction — e.g., factories needing service access, or compiler passes required so Foundry behaves inside the Symfony test kernel. If you are not on that exact combination, the value is zero, and 0.3.0 adds no new use case.
• Opportunity cost framing. Every hour spent evaluating, vendoring, monitoring, and now re-namespacing this package is an hour not spent on test coverage, CI runtime, or flaky-test reduction — the outcomes stakeholders actually care about.

When to Consider This Package

Consider it only when all of the following hold:

• You are pinned to an older Symfony (roughly 4.4/5.x) and a pre-1.0 zenstruck/foundry, and you are hitting the specific container/compiler-pass failures this bundle patches.
• You have verified the upstream Foundry docs and changelog do not already cover the fix — in most modern setups they do.
• You have read the source and are comfortable vendoring it, because you will be the maintainer in practice — including absorbing namespace changes like the 0.3.0 move yourself.

Look elsewhere — and by default, do not adopt — when:

• You are on Foundry 1.x/2.x or a currently supported Symfony release. The upstream package and its documentation are the correct answer.
• You need any maintenance guarantee: security advisories, PHP 8.2+/8.3+ compatibility, or a responsive issue tracker. None of that exists here, and 0.3.0 did not add it.
• You are already on 0.2.x. The 0.3.0 namespace/class rename is a breaking change with no compatibility shim or alias documented — upgrading means editing every reference in your code. That is the migration tax you pay for a dependency that is really reference code.
• You want a dependency your team can put in a composer.json and forget. Zero stars, zero dependents, and a rename-only release means effectively no community validation and no upgrade path.
• The need is small enough to satisfy with a short internal compiler pass or a test-case base class — which, for this problem, it usually is.

Net PM recommendation: reject as a dependency; treat as reference source code. 0.3.0 is a cosmetic rebrand, not a reason to adopt. If the underlying problem is still real for the team, allocate a small spike to internalize the fix under our own namespace.

How to Pitch It (Stakeholders)

For executives: This is a tiny, unmaintained add-on for a Symfony testing library. It solves a narrow wiring problem for older versions of the framework. Its newest release only renames its namespace and bundle class — no new features, no compatibility work, no security coverage. Adopting it would add a dependency nobody maintains, with no upgrade path, in exchange for saving perhaps a day of engineering — and would hand us a future breaking rename to absorb. The recommendation is unchanged: skip it and solve the problem internally if it still exists.

For engineering: icanhazstring/foundry-bundle supplies extra configs and compiler passes to smooth over zenstruck/foundry integration with Symfony components. Release 0.3.0 moves the namespace to icanhazstring\FoundryBundle and renames the bundle class to FoundryBundle — a BC break with no functional change and no stated Symfony/PHP/Foundry support bump. It remains glue code with no dependents and no activity. On modern Foundry and Symfony it is redundant. If we hit the specific issue on a legacy app, read the bundle's source, lift the relevant compiler pass into our own test-support code (choose our own namespace while we're at it), and move on. Do not add it to composer.json; treat it purely as a reference implementation.