- Is radish/radish-bundle a Laravel package?
- No. It is a Symfony bundle, the integration layer between the Radish BDD/spec library and Symfony's KernelTestCase and WebTestCase. There is no Laravel service provider, no config/*.php file, and no package discovery metadata, and Laravel has no bundle concept at all. It cannot be dropped into a Laravel application without a wrapper you would have to write and own.
- Can I install radish/radish-bundle with Composer inside a Laravel project?
- Composer may let it install as a dev dependency, but that does not make it functional in Laravel. The package expects a Symfony kernel to register its bundle and expose Radish services from the container, which Laravel does not provide. For readable describe/it specs in Laravel, Pest gives you the same style on top of a maintained PHPUnit core with first-party framework integration.
- What does radish/radish-bundle actually do?
- It connects the Radish spec library to Symfony's testing kernel so describe/it-style specs can boot the Symfony container and drive the functional test client. You enable it in your kernel, configure it through standard bundle settings, and access Radish services from the container. In practice it is a test-harness convenience for readable functional specs.
- Does radish/radish-bundle support PHP 8.1+ and current Symfony versions?
- Very unlikely. The last release was March 2017, which places it in the PHP 5.6 and PHP 7.0-7.1 window with Symfony 2.8/3.x-era code, meaning no typed properties and no PHP 8 attributes. Before assuming anything, read composer.json for the php, symfony/*, and radish/radish constraints and attempt resolution inside a throwaway container pinned to your target PHP. Expect conflicts with modern Symfony and PHPUnit.
- What should Laravel developers use instead of Radish Bundle for BDD-style specs?
- Pest is the direct answer: it provides the same describe/it readability on top of a maintained PHPUnit core, with first-party Laravel integration. Codeception is a heavier alternative if you also need acceptance-layer coverage. Neither requires a Symfony kernel, so you avoid vendoring a stale bundle and its dependency graph into your project.
- Is radish/radish-bundle still maintained?
- No. It has a single maintainer, no release since March 2017, one star, zero dependents, and a composite score of 0.065, so there is effectively no community validation or peer review. It is MIT-licensed, so forking is legally unencumbered, but you would transfer the entire maintenance burden in-house for a test-harness nicety.
- How do you install and enable Radish Bundle in a Symfony application?
- Add it as a dev dependency with composer require radish/radish-bundle, enable the bundle in your kernel, and configure it through standard bundle settings. Radish services then become available from the container and can be used in your specs. This only works on Symfony 2.8/3.x-era applications running a compatible PHP version; a supported Symfony LTS will not boot it without source changes.
- What are the security and CI risks of depending on an abandoned dev package?
- Dev-only dependencies still execute in CI, and an unmaintained package has no path to a CVE fix. Pinning it also forces you to pin a large, equally stale transitive graph including Radish core and Symfony test components into your dev image. The risk here is high and concentrated in abandonment, transitive exposure, and security posture.
- Should we fork radish/radish-bundle and maintain it internally?
- Only if you accept a named maintainer, a budgeted upgrade path, and a documented exit criterion before adoption. The MIT license makes a fork legally clean, but you inherit every fix, and you are doing it for a readability feature rather than a business capability. Time-box a two-to-three day spike first; if reproducing the spec syntax takes longer than that, treat it as a signal to abandon.
- Does Radish Bundle work with modern PHPUnit features like JUnit XML, parallel testing, and coverage drivers?
- Probably not. There is likely no modern PHPUnit bridge, which implies no JUnit XML reporting, no parallelization, and no coverage driver integration in your pipeline. Confirm this against the package source and a real resolution attempt before you plan any CI tooling around it. For most teams, that gap alone rules it out.