- Does pierstoval/smoke-testing work with Laravel?
- No. It is a Symfony bundle that hooks into the Symfony Kernel, Router, and test KernelBrowser/Panther stack, so the fit in a Laravel codebase is effectively zero without a rewrite. Laravel teams should look at HTTP test crawling packages instead. Treat this as a Symfony-only evaluation and do not install it expecting Laravel support.
- How do I install and configure pierstoval/smoke-testing?
- Add it to the require-dev block via Composer, register the bundle in your test kernel configuration, and point it at the route set you want crawled. It is a CI-time verification layer, not a runtime dependency, so it should never ship to production. Before merging, clear the license with legal review since the manifest reports NOASSERTION rather than a recognized SPDX identifier.
- Which Symfony and PHP versions are supported?
- Check the composer.json constraint range on the current release rather than trusting the README, because a low-traffic package can lag behind recent Symfony majors. With 39 stars and zero dependents there is little downstream pressure to keep constraints current with framework releases. Expect to pin Symfony or patch the package yourself when you upgrade majors.
- What transport does it use to crawl pages: HTTP kernel browser, Panther, or raw HTTP?
- This determines your CI cost and flake profile, so verify it against the source for the current major before committing. If it relies on Symfony Panther, your CI images need Chrome and Chromedriver, which adds build weight and a new source of flakiness. A plain kernel browser is far cheaper but will not catch JavaScript errors.
- How are authenticated routes and CSRF-protected forms handled?
- The package cannot infer your auth strategy, so the integrating team must curate an allow or deny list, or supply an authenticated session fixture. Excluding too many routes creates false confidence: a green run that skips most of the app is worse than no run because it gets cited as coverage. Plan this curation as real work, not a config afterthought.
- Can I run it in CI on every deployment?
- Yes, that is the intended use, ideally as a dedicated PHPUnit suite or a console command invoked from your pipeline. The real cost is infrastructure: you need a bootable app, a disposable seeded database, and any external services stubbed or faked. Routes must be safe to hit repeatedly, so avoid crawling anything with third-party side effects on GET.
- Is smoke testing a replacement for unit and integration tests?
- No, it complements them. It answers one narrow question cheaply: does every routed endpoint at least resolve and render without throwing an unhandled exception. That makes it a useful regression net after dependency upgrades, framework majors, or configuration changes, but it will not validate business logic or edge cases.
- What license does pierstoval/smoke-testing use, and is it safe for commercial use?
- The manifest reports NOASSERTION, which does not map to a recognized SPDX identifier, so legal and OSS review must clear it before it lands in a commercial repository. Do not merge it on the assumption that it is MIT. This ambiguity is a procurement blocker, not a formality.
- Is the package actively maintained?
- The maintenance signal is the dominant risk: 39 stars, zero dependents, a low opportunity score around 24.4, and no stated support policy. Zero dependents means nobody else feels the pain if the maintainer walks away, so budget for owning a fork. Check release cadence over the last 18 months before adopting.
- Does it fail only on exceptions, or also on non-2xx responses and console errors?
- Confirm this against the docs and source for the current major, because it changes what a green run actually means. Some setups flag only unhandled exceptions, while others assert on status codes and browser console output. Configure expectations explicitly so non-2xx redirects and soft failures do not silently pass.