Request Service Php Lib Laravel Package

Getting Started

Read the diff before the README. The 8.0.0 release notes contain exactly one line — "Feature/update php84 version" (PR #4, first-time contributor) — so the release notes tell you almost nothing. The actual contract lives in two places:

1. composer.json on the 8.0.0 tag — specifically require.php and require.illuminate/*. A major bump whose only stated change is a PHP version is almost always a raised platform floor, and possibly a widened or narrowed Laravel constraint.
2. The full diff at compare/7.0.0...8.0.0. Look for changed method signatures, added return types, readonly/typed properties, and anything touching exception classes.

Install (verify the floor first):

composer require not-empty/request-service-php-lib:^8.0 --dry-run

If you are on PHP 8.2 or 8.3, that dry run will fail — that is the whole story of this release. Pin ^7.0 and move on until your runtime is 8.4.

First use case. This package is a request-service abstraction: it moves the body of a controller action (authorization, validation, orchestration, persistence) into a dedicated, injectable service class, leaving the controller to translate HTTP in and out. Pick your ugliest controller action — the one with 80 lines, three if guards, and a DB::transaction in the middle — and port only that one. Do not refactor the codebase on the strength of a one-line changelog.

Where to look first, in order: src/ for the base class or interface you extend/implement → the package's test suite (it is the de facto documentation for a package this thin on docs) → your own tests/Feature for the controller you are about to touch.

Implementation Patterns

One service per use case, not per model. The pattern pays off when a service maps to a single application action — RegisterUser, CancelSubscription — and not to a resource. Services that mirror Eloquent models drift back into fat classes within a month.

Bind, don't new. Register the service in a service provider (or rely on the container's autowiring) and inject it into the controller constructor or the action method. This is what makes the pattern testable and what lets you swap a fake in tests without touching the controller.

// app/Http/Controllers/RegistrationController.php
public function __invoke(RegisterUserRequest $request, RegisterUser $service): RedirectResponse
{
    $service->handle($request->validated());

    return redirect()->route('dashboard');
}

Keep HTTP concerns in FormRequests. The service should accept plain validated data or a DTO, never an Illuminate\Http\Request. The moment a service takes a Request it becomes untestable outside a request lifecycle and couples your domain to the framework.

Wrap the side effects, not the validation. Put the DB::transaction(...) inside the service, around the writes. Validation and authorization stay in the FormRequest/Policy layer where Laravel's error handling already knows how to render them.

Test the service directly. A service with a DTO input gets a plain unit test with no HTTP scaffolding:

it('registers a user', function () {
    $service = app(RegisterUser::class);

    $user = $service->handle(new RegisterUserData(
        name: 'Ada', email: '[email protected]',
    ));

    expect($user)->toBeRegistered();
});

Integration tip for the 8.0 upgrade itself: add PHP 8.4 to your CI matrix before bumping this dependency, not after. Run the upgrade as its own commit so that if the major version also changed a signature (likely, given it is a major), the failure is attributable.

Gotchas and Tips

PHP 8.4 implicitly nullable parameters are deprecated. This is the single most likely source of noise after upgrading, and it applies to your code as much as the package's: function handle(SomeDto $dto = null) now emits E_DEPRECATED and must be written ?SomeDto $dto = null. If your test suite converts deprecations to failures (PHPUnit's convertDeprecationsToExceptions, or Pest's strict mode), an 8.4 runtime will light up red on code you did not touch in this upgrade. Fix the signatures rather than relaxing the setting.

A major bump with one changelog line means unlogged breaking changes. Treat 8.0.0 as "unknown surface area changed." Grep your codebase for every class you extend or interface you implement from this package and diff those specific files between tags. Semantic-versioning discipline varies enormously across small packages; the version number is a claim, not a guarantee.

Do not assume the Laravel constraint moved in lockstep. The PR is titled as a PHP update. A package can support PHP 8.4 while still capping illuminate/support below your Laravel version, or vice versa. Read both constraints from composer.json before concluding the upgrade is safe on your framework version.

Stuck on 7.x? That is a legitimate outcome, not a failure. The 7.0.0 line remains installable; if the only delta is the PHP floor, staying put costs you nothing until 8.4 is on your roadmap. Record the pin in your upgrade notes so it does not get silently bumped by a composer update.

Debugging the pattern itself. When a service silently does nothing in a controller, the usual cause is a route-model-bound or container-resolved instance shadowing the one you constructed in a test — construct services via app() in tests so you exercise the same binding graph production uses.

Extension points worth knowing. For a package this small, the intended customisation surface is almost always: extend the provided base class, or implement the interface directly and bind your implementation. Prefer the interface — it survives the next major bump, since base classes with concrete helper methods are exactly what gets refactored between majors.

Watch the contributor signal. @brunavitoria is a first-time contributor and this is the entire 8.0.0 release. Not disqualifying, but it means the maintainer's review of a major-version change from a new contributor is the thing you are trusting. Skim the PR conversation; if there is none, weight your own test run more heavily than usual.