Foundry Bundle Laravel Package

Technical Evaluation

Architecture fit — framework mismatch remains the headline finding; 0.3.0 does not change it. Despite the brief labeling this a Laravel/PHP package, icanhazstring/foundry-bundle is a Symfony bundle (Bundle subclass + DI compiler passes) built to smooth over friction in zenstruck/foundry. It has no Laravel service provider, no Eloquent integration, and no Facade/Container binding surface that a Laravel application could consume. For a Laravel codebase the architecture fit is effectively zero — there is nothing to register and nothing to boot. Even in a Symfony codebase, the package's value proposition is narrow: it adds config nodes and compiler passes that auto-tag/auto-register Foundry factory services, which is functionality Foundry itself absorbed in later releases.

What 0.3.0 actually is — a rename, not a feature. The release contains exactly two changes: the namespace moved to icanhazstring\FoundryBundle, and the bundle class was renamed to FoundryBundle. There are no new capabilities, no dependency constraint bumps, no PHP/Symfony version widening, no bug fixes, and no security-relevant change. In TPM terms this is a cosmetic refactor packaged as a release, and it is semver-breaking: 0.x permits it, but it breaks every consumer and every existing fork regardless.

Technical risk — still high, with one new category added. Last functional release was 2021-08-26; 0.3.0 arrives after roughly four years of drift and touches only naming. Zero stars and zero dependents remain the signal of an unmaintained, single-author, essentially unexercised artifact. The pre-existing risks stand unchanged:

• Constraint drift: composer requirements likely still target PHP 7.x/8.0 and Symfony ^4/^5, blocking PHP 8.2/8.3 and Symfony 6/7 without a fork. 0.3.0 does not address this — the single highest-value fix the maintainer could have shipped was skipped in favor of a rename.
• Container-build fragility: compiler passes execute at cache warmup, so a Symfony minor upgrade can turn a working deploy into a hard container compile failure with no upstream fix.
• No security response path: MIT permits forking, but there is no disclosure or patch channel and no CVE history.
• Correctness risk from low coverage: 0 dependents means edge cases (multi-entity-manager setups, custom factory namespaces, PersistentProxyObjectFactory) are almost certainly untested.

New risk introduced by 0.3.0 — a hard namespace break with no BC shim. The FQCN change ripples through every place a bundle is referenced by name, and nothing in the notes suggests a class alias, deprecated shim, or upgrade guide was provided:

• config/bundles.php registration (FoundryBundle::class) fails to resolve until edited.
• Service IDs and DI references derived from the old FQCN break.
• Compiler pass registration and any getContainerExtension() alias / config root name change with the class.
• Existing vendor forks, if any were taken against the old namespace, can no longer fast-forward — they must be re-forked or manually rebased.
• Changelog quality is itself a finding: the note reads "Moved namespace from to icanhazstring\FoundryBundle" — the source namespace is literally omitted. A consumer cannot determine from the release notes what to search-and-replace. That is a documentation-discipline signal consistent with the rest of the evidence.

The one charitable read: someone is still at the keyboard, so the project is not formally abandoned. That does not convert into a support commitment, and it does not retire a single item on the risk list.

Key questions for the team:

1. Which Foundry and Symfony versions does 0.3.0 declare, and does our pinned stack intersect? (The release notes do not say — verify in composer.json directly.)
2. What is the old namespace, and is a class alias / BC layer shipped for it?
3. What specifically do the compiler passes do that Foundry's own bundle config does not already handle today?
4. Is the underlying pain point (factory service registration, autowiring, resetting state between tests) still present, or already solved by dama/doctrine-test-bundle + native Foundry?
5. Does an actively maintained fork or successor exist — and if we already maintain a vendor fork, do we absorb the rename or stay pinned to the pre-0.3.0 tag?
6. Who owns the fork when PHP 8.4 / Symfony 8 lands?

Verdict: unchanged — do not adopt; the composite score of 0.1 is consistent with the evidence. 0.3.0 is a breaking rename that resolves nothing on the risk register, so it reinforces rather than softens the recommendation.

Integration Approach

Stack fit. Symfony + Doctrine only. If the target application is Laravel, stop here — there is no integration path, and the closest Laravel analog (Pest/PHPUnit + Eloquent model factories + DatabaseTransactions) needs no third-party glue. If the target is Symfony, fit is conditional on version pinning, and 0.3.0 makes the pinning decision more consequential, not less.

Migration path (Symfony, if genuinely needed). Treat this as a bridge to be removed, not a dependency to be adopted:

1. Audit the two or three compiler passes; document each behavior in one line.
2. Verify each behavior against native Foundry config on the version we run.
3. Replace each pass with either native config or ~20 lines of in-house PassConfig code we own.
4. Delete the dependency and the composer entry.

Handling the 0.3.0 rename. There is no functional reason to take this release. Decide explicitly rather than drifting into it:

Compatibility. Expect to fork and re-tag regardless of which version you land on:

Sequencing. Do not sequence this into a migration as a dependency. Sequence it as: (a) spike in a throwaway branch, (b) prove the passes are redundant, (c) write the two-line native replacement, (d) close the spike. Time-box to a day. If a production legacy app truly depends on it, invert: fork → vendor → pin to a commit SHA on the pre-0.3.0 tag → ADR recording that we own it. Add an explicit note in the ADR that upstream has moved namespaces and we have chosen not to follow.

Operational Impact

Maintenance. Effectively zero upstream maintenance, now with evidence of directionless churn. Four years of silence followed by a breaking rename — not a version bump, not a dependency widening — tells us the maintainer's attention is on cosmetics while the constraint drift that actually blocks consumers goes unfixed. Zero stars and zero dependents mean no issue triage, no PR review, no dependency bumps. Any ongoing cost is fully transferred to our team. Budget it as "we own a small fork," not "we consume a package."

Support. No community, no documentation beyond the README, no Stack Overflow corpus, no vendor. 0.3.0 makes this marginally worse: the changelog omits the source namespace, so even the one artifact a consumer would consult for upgrade guidance is incomplete. Knowledge is concentrated in one author and whatever source we can read. On-call runbooks must be written by us.

Scaling. Runtime overhead is negligible — compiler passes run once at container build and are then cached, so request-path performance is unaffected. The scaling concern is organizational: every PHP/Symfony upgrade, and now every upstream rename, is a potential container-compile blocker gated on a fork we may have forgotten about.

Failure modes to instrument:

• Container compile failure after a Symfony, Foundry, or namespace upgrade — surfaces at deploy, not at test time. Mitigate with a CI job that runs cache:warmup on the target PHP matrix.
• Class-not-found on the old FQCN post-0.3.0 — bundles.php, DI config, and compiler pass registrations all reference the class by name. Fails hard and early, which is the good case; the bad case is a stale opcache/classmap resolving a half-migrated tree.
• Silent service mis-tagging — factories stop being registered, tests fall through to real fixtures or fail with confusing autowire errors.
• Stale compiled container in long-lived environments masking the above until a cold deploy.
• Test-state leakage if the package's reset behavior overlaps or conflicts with dama/doctrine-test-bundle.
• Security advisory blind spot — no upstream to publish; add to composer audit allowlist review with an explicit owner.
• Divergent vendor forks — if two teams re-fork independently, one on the old namespace and one on the new, you get duplicate bundle registration and confusing double-config. Mandate a single owned fork.

Ramp-up. Learning curve for the code itself is low (a bundle plus a few passes is readable in an hour). Ramp-up risk is bus factor, not complexity: no external references, so a new engineer must reverse-engineer intent from source — and after 0.3.0 must also reconstruct the namespace history, since upstream did not document it. Assume half a day of onboarding for whoever inherits the fork, plus an hour for the rename archaeology, and record decisions in an ADR at adoption time.

Bottom line for operations: 0.3.0 is a breaking rename that solves none of the problems that made this package a poor bet, and it adds a migration cost on top. The package remains a permanent, low-frequency, high-severity upgrade tax in exchange for solving a problem current Foundry configurations already solve. The defensible TPM position is to decline it, pin away from 0.3.0 if already entangled, and spend the half-day writing the native equivalent in-house.