- Can I use mano/autotest-bundle in a Laravel application?
- Only nominally. Composer will resolve and install mano/autotest-bundle in a Laravel project, but the package is a Symfony bundle registered through Symfony's Bundle class and DependencyInjection extension. Laravel has no matching boot path, no service provider is shipped, and nothing will register or run. Treat it as a design reference to reimplement, not a working dependency.
- Is mano/autotest-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle. It hooks into the Symfony Router and the PHPUnit bridge, and it is registered via Symfony's Bundle class and DependencyInjection extension. The v1.1.2 change modifies a resolver interface to return a route decorator inside that Symfony-specific resolver chain; it does not add a framework-agnostic entry point or a Laravel service provider.
- How do I install mano/autotest-bundle?
- Install with composer require mano/autotest-bundle. In a Symfony application you then register the bundle and configure the DependencyInjection extension. In Laravel the install succeeds but no provider, config, or test runner integration is booted, so installation alone gives you no working workflow.
- Does mano/autotest-bundle support Laravel 10, 11, or 12?
- There is no documented Laravel version support. The package exposes no Laravel service provider, facade, config merge, or framework-agnostic entry point, so Laravel 10, 11, and 12 are effectively unsupported. Also re-verify Composer constraints, because a functional change without a platform-support change does not confirm Symfony 6.4/7.x or PHP 8.2+ compatibility.
- What changed in mano/autotest-bundle v1.1.2?
- The release alters the resolver interface to return a route decorator. That is internal plumbing inside the Symfony resolver chain, not a new portable data provider or Laravel seam. It is also a breaking change to a public extension point shipped as a patch version, which raises semver and release-process concerns for anyone pinning to upstream.
- Is mano/autotest-bundle actively maintained?
- The picture is mixed. A release after roughly three years contradicts a simple abandonment claim and is a genuine, if thin, signal of a living maintainer. But the package has no dependents, about three stars, and no support corpus, so verify the actual release date, changelog, and Composer constraints rather than trusting old assumptions.
- What is the route decorator abstraction and can I port it to Laravel?
- The decorator implies the resolver emits a normalized wrapped route object carrying path, verbs, parameters, and likely metadata instead of a raw framework route. That is exactly the seam a Laravel harness would need to reproduce. It shortens the design-reading part of a porting spike and makes the resulting harness more accurate, but it does not materially reduce the one-to-two-day build estimate.
- What are the production risks of auto-generated route tests?
- Auto-generated route tests execute real endpoints, so against a non-isolated environment they can mutate state, fire jobs, send mail, or trip rate limiters. A route decorator layer can increase that surface because decorated routes are more likely to be dispatched faithfully with correct verbs and real parameters instead of being safely defaulted to GET. Isolate the environment and use transactions or fakes before running them.
- What are Laravel alternatives to mano/autotest-bundle?
- Use PHPUnit or Pest with Laravel's HTTP testing helpers and feature tests, and generate route inventories with route:list. For browser flows, Laravel Dusk or a similar tool covers end-to-end checks. The autotest concept is portable, but in Laravel you should reimplement the pattern rather than wrap the Symfony bundle.
- Should I fork mano/autotest-bundle or depend on it?
- Do not pin to the upstream artifact casually. Changing a resolver return type in a patch release means either semver discipline is absent or the interface is not considered public, so there is no stability contract on the part you would most want to copy. If you fork, track upstream by diffing rather than upgrading, and assign clear ownership of the fork.