Response Bundle Laravel Package

Getting Started

First, the reality check: this is a Symfony bundle, not a Laravel package. There is no service provider, no auto-discovery, no facade. If your day-to-day is Laravel, you will almost never install this directly — it is infrastructure for a small family of response-* bundles by the same author (response-common holds the actual logic; this bundle is the Symfony wiring plus shared enums).

If you are in a Symfony codebase (or maintaining a library that must support both), the minimal path is:

composer require mrgoodbytes8667/response-bundle

Then register it in config/bundles.php (order matters — this one should come before any child response bundle that depends on it). There is nothing to publish and likely nothing meaningful to configure on its own.

Where to look first, in this order:

1. vendor/mrgoodbytes8667/response-common/ — this is where the behaviour lives. Read this before the bundle.
2. The src/Enum (or src/Enums) directory of the bundle itself — the enums are the actual product of this package. Check for new values after major/minor bumps (see Gotchas).
3. composer.json of any child bundle you're considering — check which version range of this bundle it pins, because that is the version you'll get whether you like it or not.

First use case: don't write code against this bundle. Instead, confirm what pulled it in (composer why mrgoodbytes8667/response-bundle), then use its enums at the boundary of your own code — e.g. a controller or DTO that needs to declare a response format/content type and wants to stay consistent with whatever the child bundles emit. The value is agreement, not features.

Implementation Patterns

Transitive-dependency pattern (the normal one). You require a child bundle (…-json-response-bundle, …-html-response-bundle, or whatever the author ships) and this arrives as a dependency. Your code should consume the child bundle's services and use this bundle's enums only as the shared vocabulary. Do not add explicit require lines for this package unless you actually reference it — otherwise you're pinning a transitive dep you don't control.

Enum-as-shared-contract. The genuine day-to-day leverage: typed enums let you pass a format/content type through your own layers without stringly-typed arguments.

use Mrgoodbytes8667\Response\Enum\ResponseFormat; // verify exact FQCN in vendor/

public function __construct(private ResponseFormat $format = ResponseFormat::Json) {}

Because PHP enums are final-ish and comparable by identity, this is safe to use in match expressions and in tests:

$this->assertSame(ResponseFormat::Json, $response->getFormat());

Expect new enum cases to land in minor releases. v6.1.0 added two JSON content types on a minor bump. Treat every non-exhaustive match on a vendor enum as a runtime hazard: either always include a default arm, or run composer update deliberately and re-check the enum. This is the single most likely source of "worked yesterday, fatal error today" with this package.

Configuration-driven defaults. Most bundles of this shape expose a small tree for a default format and a list of enabled formats/child bundles. Check with:

bin/console config:dump-reference response   # adjust the alias to match
bin/console debug:config response

Keep your app's default in config/packages/response.yaml rather than hardcoding a format in controllers — that's the seam the author intended.

Entity traits/interfaces. The bundle also ships CRUD helpers — a CreatedUpdatedTrait, a CreatedUpdatedEntityInterface, and a BytesResponseExtension. If you adopt CreatedUpdatedTrait for audit timestamps, pin the minor version: v6.1.0 changed the trait's function defaults and added an interface method. These are quiet behavioural changes that do not show up in a type check.

use Mrgoodbytes8667\Response\…\CreatedUpdatedEntityInterface;

class Post implements CreatedUpdatedEntityInterface
{
    use CreatedUpdatedTrait;
}

Cross-bundle consistency. If you write your own response factory or serializer alongside the child bundles, type its input with this bundle's enum. That way adding a new child bundle later doesn't force a refactor of your call sites.

Laravel-side pattern, if you're determined. You cannot boot this bundle in Laravel. But the enums are plain enum classes with (presumably) no framework coupling. The pragmatic move is to treat them as a specification: read them, then define your own equivalent enum in app/Enums and map at the boundary. Reusing them via composer require works for pure enum value access, but you inherit a Symfony-flavoured dependency tree for what amounts to a handful of constants.

Gotchas and Tips

• No auto-discovery. In Laravel, composer require will do nothing useful. Don't spend an hour looking for the service provider — there isn't one.
• Zero stars, zero dependents, last release Nov 2024. There is no community, no Stack Overflow trail, and no guarantee of a security response. Treat the source as the only documentation, and read it before you build on it.
• License is NOASSERTION. That is not a license grant. Get a human to clear it before this reaches production, especially in a commercial codebase.
• Version pinning is the real risk. Because child bundles constrain this package, a composer update of an unrelated child bundle can move this one under you. Run composer why before and after, and pin the child bundles explicitly with ^x.y rather than *.
• Minor releases are not "safe" here. v6.1.0 is labelled a feature release but adds a method to CreatedUpdatedEntityInterface (breaking for anyone who implements it without the trait), changes CreatedUpdatedTrait defaults (silent behaviour change), and adds enum cases (breaks exhaustive match). Pin to a patch-level range (~6.1.0) if you use the CRUD interfaces or enumerate the content types.
• Doctrine ORM ^3.0 is now allowed. This widens your dependency resolution but does not imply first-class testing against ORM 3 in every child bundle. If a composer update suddenly drags in DBAL/ORM 3, verify your own entities and migrations before assuming the bundle caused the problem — it likely just unblocked it.
• Enum name collisions. If you already have App\Enum\ResponseFormat or similar, importing the vendor one silently changes type-checking behaviour in match/instanceof. Alias imports (use … as VendorFormat;) rather than mixing.
• Bundle registration order. Symfony bundles that register compiler passes and depend on a sibling's services will fail with an obscure "service not found" if listed after the child. Register this one first.
• BytesResponseExtension return types changed to void in v6.1.0. Harmless if you only call load/prepend, but it will fatal if you subclass and declare a non-void return.
• Debugging. bin/console debug:container --tag=…, bin/console debug:config <alias>, and bin/console about to confirm the bundle is actually registered. If the enums are right but the response is wrong, the bug is in response-common, not here.
• Extension points are narrow. The public surface is essentially the enums plus CreatedUpdatedEntityInterface and BytesResponseExtension. Beyond those, don't subclass the bundle's services — you'll be relying on private structure that a patch release can break.
• The honest recommendation: for a Laravel application, do not adopt this. For a Symfony application already using the author's child bundles, use it exactly as designed — as a passive dependency whose enums you consume at your boundaries, with a pinned version and a licence review on file.