- What is kami/request-processor used for?
- It is a strategy-based request processor for PHP and Laravel projects that lets you break incoming HTTP request validation, normalization, and handling into small, reusable, testable classes. The TPM assessment notes it overlaps heavily with Laravel middleware, form requests, and Illuminate Pipeline. It fits best in bounded contexts where request orchestration is genuinely bespoke and currently spread across controllers, jobs, and observers.
- How do I install kami/request-processor in Laravel?
- It is installed as a Composer package, with a small surface area that likely includes a service provider, config file, and an interface to implement. The assessment says a spike is measured in hours rather than days. However, it recommends not taking a Packagist dependency because the package is effectively abandoned and was last released in January 2022. The lower-risk path is to fork and vendor the source internally or reimplement the abstraction over Illuminate Pipeline.
- Is kami/request-processor compatible with Laravel 10 or 11?
- Composer may install it on a modern Laravel, but the illuminate and PHP version constraints were written against a 2021-era stack. Running it on Laravel 10 or 11 is untested territory at best and a hard incompatibility at worst. You should verify the actual illuminate constraint range before writing any code. The assessment also warns it may depend on framework internals that Laravel has since changed.
- How does kami/request-processor compare to Laravel middleware and Pipeline?
- It overlaps heavily with what Laravel already provides through HTTP middleware, form requests, Illuminate Pipeline, and queued jobs. Adopting a parallel processor abstraction creates a second competing mental model for things that happen to a request. That conceptual duplication is the primary architectural cost. The package is only worth considering where request orchestration is genuinely bespoke and not well served by existing framework primitives.
- Should I use kami/request-processor in production?
- The TPM assessment does not recommend owning it as a production dependency. It has one star, zero dependents, a last release in January 2022, a single-maintainer vendor namespace, and no observable CI, static analysis, or security advisory pipeline. Bus factor is one, and the maintainer has not shipped in over three years. Treat it as a reference implementation and either fork it internally or reimplement the pattern.
- What are the alternatives to kami/request-processor?
- Laravel already offers middleware, form requests, Illuminate Pipeline, queued jobs, and command bus patterns for request orchestration. The assessment suggests the abstraction is likely only 200 to 400 lines of straightforward orchestration over Illuminate Pipeline. Reimplementing it behind an application-owned interface avoids the supply-chain and abandonment risk. Fork-and-vendor is the other viable path if you want to preserve the original design.
- How do I test request processors built with kami/request-processor?
- The small, reusable processor classes are inherently testable in isolation, which is the main design benefit. However, the assessment found no evidence of meaningful test coverage, CI, or static analysis in the package itself. You should write your own unit tests for each processor step and integration tests for the full pipeline. If you fork the source internally, add CI and static analysis to pin it to your PHP and Laravel matrix.
- What is the maintenance status of kami/request-processor?
- It is effectively abandonware by objective measures: one star, zero dependents, a last release in January 2022, and a single-maintainer vendor namespace. There is no ecosystem validation, no downstream bug reports to learn from, and no observable security advisory pipeline. The maintainer has not shipped in over three years. The assessment recommends evaluating it as a reference implementation rather than a dependency.
- Does kami/request-processor integrate with Laravel service container and facades?
- The assessment flags this as an open question because request processor is ambiguous marketing. You must determine whether the package is Laravel-aware with a service provider, container bindings, and facades, or framework-agnostic. That answer determines whether it is portable or locked to a specific illuminate range. You should also verify the actual contract: a middleware-style chain, a command bus, or a request DTO hydrator.
- Can I fork kami/request-processor and maintain it internally?
- Fork-and-vendor is one of the two viable paths recommended by the assessment, provided the license and provenance allow legal internal maintenance. You would copy the source into app/Support/RequestProcessing or an internal packages directory, drop the Composer constraint, and pin it to your PHP and Laravel matrix. That removes the supply-chain and abandonment risk and turns the question into ordinary internal code ownership. Confirm the maintainer is reachable for security disclosures, or assume the repository is dormant.