Radish Bundle Laravel Package

Technical Evaluation

Architecture fit. The first finding is a stack mismatch that must be resolved before any deeper evaluation: radish/radish-bundle is a Symfony bundle, not a Laravel package. It is the integration layer between the Radish BDD/spec library and Symfony's KernelTestCase/WebTestCase, exposing describe/it-style specs that boot the Symfony container and drive the functional test client. Laravel has no bundle concept — there is no service provider, no config/*.php, no Laravel discovery metadata — so it cannot be dropped into a Laravel application without a wrapper we would have to write and own. Even within a Symfony estate, fit is limited to legacy (Symfony 2.8/3.x-era) applications.

Integration feasibility. Feasibility is low and should be time-boxed to a short spike. The package's last release is March 2017, which places it in the PHP 5.6/PHP 7.0–7.1 window; modern PHP 8.1+ and current Symfony/PHPUnit versions are very unlikely to resolve in Composer. A fork-and-patch path exists but transfers the entire maintenance burden in-house for a test-harness nicety.

Technical risk. High, concentrated in three areas. (1) Abandonment: one star, zero dependents, single maintainer, no release in eight years, and a composite score of 0.065 — there is effectively no community validation or peer review. (2) Transitive exposure: the bundle pulls Radish core plus Symfony test components; pinning it forces pinning a large, equally stale dependency graph into our dev image. (3) Security posture: dev-only dependencies still execute in CI, and an unmaintained package has no path to a CVE fix. Mitigating factor: it is MIT-licensed, so a fork is legally unencumbered.

Key questions.

• Is the target application Laravel or Symfony? If Laravel, this evaluation ends at "not applicable."
• What capability gap are we trying to close — readable spec syntax, functional HTTP testing, or living documentation — and why don't PHPUnit, Pest (Laravel), or Behat/Codeception (Symfony) cover it?
• Are we willing to own a fork indefinitely, with a named maintainer and a budgeted upgrade path?
• What is the test suite's expected lifespan, and does the surrounding app even run on a PHP version this bundle supports?
• Has anyone verified composer require actually resolves against our current lockfile, or is this assessment theoretical?

Integration Approach

Stack fit. Poor for a Laravel target — treat as a hard no at the framework level. For a Symfony target it fits conceptually (it is a first-class bundle with a DI extension) but not temporally; assume it will not boot on a supported Symfony LTS without source changes.

Migration path. The recommended path is not to migrate onto this package, but to migrate the intent. For Laravel, Pest provides the same describe/it readability on top of a maintained PHPUnit core, with first-party framework integration. For Symfony, PHPUnit plus Behat or Codeception covers functional and acceptance layers. If the Radish DSL itself is the requirement, budget a time-boxed (2–3 day) spike to determine whether a maintained spec runner can reproduce it; treat anything longer as a signal to abandon.

Compatibility. Verify explicitly rather than assuming: read composer.json for php, symfony/*, and radish/radish constraints, then attempt resolution in a throwaway container pinned to our target PHP. Expect conflicts. There is no PHP 8 attributes support, no typed properties, and likely no modern PHPUnit bridge — meaning no JUnit XML, no parallelization, no coverage driver integration.

Sequencing. (1) Confirm framework target and close out if Laravel. (2) If Symfony, run the composer resolution spike in an isolated Docker image before touching the main repo. (3) If resolution succeeds, vendor the package into an internal fork under our namespace, pin the full dependency graph, and run one representative functional spec as a proof of concept. (4) Only after that, decide adoption — with a documented exit criterion and a successor plan. (5) Never introduce it as a second test DSL alongside PHPUnit without team agreement; two runners is a durable tax.

Operational Impact

Maintenance. This is the dominant cost. An abandoned bundle means every PHP, Symfony, or PHPUnit upgrade becomes our patch to write. Assume the fork becomes internal infrastructure and staff it accordingly — realistically a few days per major upgrade cycle, plus opportunistic fixes.

Support. There is no upstream support channel, no issue triage, and one star's worth of community. Internal Slack-plus-wiki documentation would need to be authored from scratch; there is no external documentation to lean on.

Scaling. Test-harness scaling is bounded by the runner: no native parallel execution, no sharding, no standard machine-readable output means CI dashboards and flaky-test analytics lose their input. Large suites will serialize and lengthen the pipeline, which compounds into developer experience and merge-queue throughput.

Failure modes. Expect silent skipping of specs if the kernel fails to boot, opaque fatals on PHP version drift, and Composer resolution failures that block the whole build (dev dependency lock-in). The most dangerous mode is quiet: teams stop trusting a red suite and start ignoring it.

Ramp-up. The DSL itself is small and learnable in under an hour — describe, it, before/after, matchers — but with no docs, engineers learn by reading source. The larger cost is cognitive: introducing a bespoke spec style into a PHPUnit-standard team splits idiom, complicates onboarding, and makes pair review harder. Estimate one to two sprints before the team is net-productive, versus near-zero for Pest or PHPUnit.

Recommendation. Do not adopt. The framework mismatch is disqualifying for a Laravel estate; the abandonment and zero-usage signals are disqualifying elsewhere. Capture the underlying need (readable specs, functional HTTP coverage) and satisfy it with a maintained, first-party-supported alternative.