Request Processor Laravel Package

Getting Started

This is a very small, low-traffic package (1 star, no dependents, last release January 2022), so treat the README and source as the source of truth rather than assuming Laravel conventions. Start here:

1. Install and inspect.

   composer require kami/request-processor
   

   Then open vendor/kami/request-processor/composer.json to check the PHP and illuminate/* version constraints. If it targets Laravel 8/PHP 7.4, expect friction on Laravel 10/11.

2. Find the entry point. Look for:

   • A service provider (src/*ServiceProvider.php) registered via package discovery.
   • A config file (config/request-processor.php) and whether it is publishable (php artisan vendor:publish --tag=...).
   • The main contract/interface — likely a RequestProcessor or Processor interface with a handle()/process() method.

3. First use case. The canonical workflow for a "request processor" is: take an incoming Illuminate\Http\Request, run it through one or more processors (normalization, validation, enrichment, authorization, logging), and return either a modified request or a response. A minimal first test:

   $processor = app(\Kami\RequestProcessor\...::class);
   $result = $processor->handle($request);
   

   Wire it into a single route or a test case before touching middleware or global config.

4. Verify before committing. Write a throwaway test against the package's own test suite (vendor/kami/request-processor/tests) to confirm it installs and runs in your Laravel version. Given the age, this is the fastest way to discover incompatibilities.

Implementation Patterns

Because the package surface is small, most day-to-day value comes from how you compose it rather than from features it ships.

Pipeline composition. If the package exposes a processor contract, build a chain:

class ProcessorPipeline
{
    public function __construct(private array $processors) {}

    public function process(Request $request): Request
    {
        foreach ($this->processors as $processor) {
            $request = app($processor)->handle($request);
        }
        return $request;
    }
}

Register the pipeline in a service provider and resolve it from a form request, middleware, or controller.

Middleware integration. The most ergonomic Laravel pattern is a thin middleware that delegates to the processor:

public function handle($request, Closure $next)
{
    $request = app(ProcessorPipeline::class)->process($request);
    return $next($request);
}

Apply it per-route group so you only pay the cost where needed.

Form request integration. If processors do normalization/validation, override prepareForValidation() in a base form request to run the pipeline, keeping controllers clean.

Testing pattern. Unit-test each processor in isolation with a constructed Request, then one feature test through the middleware. Assert on the request object ($request->input(...), headers, attributes) rather than on internal state.

Configuration-driven processors. If the package supports a config array of processor classes, prefer that over hardcoding — it lets you toggle processors per environment (e.g., verbose logging processors only in local).

Gotchas and Tips

• Maintenance risk. Last release 2022-01-04, 1 star, 0 dependents. Pin the version in composer.json and be prepared to fork or vendor the code. There is no community to lean on for bug reports.
• Version constraints. Check illuminate/support and illuminate/http bounds. On newer Laravel installs, composer require may fail or silently resolve an old Laravel — verify with composer why-not kami/request-processor.
• Auto-discovery may not be present. On a 2022 package it likely is, but confirm extra.laravel.providers exists; otherwise register the provider manually in config/app.php.
• No published config = defaults are hidden. Read the config file in vendor/ directly. If it reads env vars, document them in your .env.example.
• Ordering bugs are silent. In a processor pipeline, a processor mutating the request after validation runs will not re-trigger validation. Log processor order at boot in local to catch misconfiguration.
• Request immutability. Laravel requests are mutable via $request->merge() / $request->attributes->set(), but Request instances passed through middleware can be replaced. Ensure your pipeline returns the request and that the middleware uses the returned instance ($request = $pipeline->process($request)), not the original.
• Exception handling. Decide early whether processors throw (ValidationException, AuthorizationException) or return responses. Throwing integrates best with Laravel's handler; returning responses requires your middleware to short-circuit.
• Debugging. Since the package is small, add Log::debug() around each processor call; there is unlikely to be built-in instrumentation. Use dd($request->all()) between processors when diagnosing ordering.
• Extension points. If the contract is an interface, implement it in your app for custom processors rather than subclassing package classes — this insulates you from a fork if the package is abandoned.
• Consider alternatives. For simple request transformation, Laravel middleware, form requests, and Pipeline (from illuminate/pipeline) cover most of this without an extra dependency. Only adopt this package if its specific processor abstraction saves you real code.