Request Log Bundle Laravel Package

Getting Started

First, verify what you're actually installing. Despite the Composer-style name, this is a Symfony bundle (MrocaRequestLogBundle), not a Laravel package. There is no service provider, no config/request-log.php to publish, and no Facade. If your application is Laravel, you have three realistic options:

1. Use it inside a separate Symfony service that fronts the API you want to record.
2. Lift the mock-generation logic out of the bundle's source (it's small) into a Laravel test helper.
3. Skip it entirely and use Laravel's built-in Http::fake() / Http::record()-style workflows.

Minimal steps if you do have a Symfony app in the stack:

composer require --dev mroca/request-log-bundle

// config/bundles.php
return [
    // ...
    Mroca\RequestLogBundle\MrocaRequestLogBundle::class => ['dev' => true, 'test' => true],
];

Where to look first, in this order:

1. README.md — the only real documentation; expect it to be terse.
2. src/DependencyInjection/Configuration.php — this is the authoritative list of config keys. Anything the README omits lives here.
3. src/Resources/config/ — service definitions, which tell you what the bundle actually wires up and what you can override.
4. The storage layer (filesystem writer, Doctrine entity, or profiler data collector) — this determines where logs land.
5. The mock generator / console command — this is the reason to use the bundle at all.

First use case: record a single real outbound HTTP call against a sandbox API in your dev environment, then generate a mock from it so your test suite can replay that response without hitting the network. That's the whole value proposition — record once, replay forever.

Implementation Patterns

Record-then-replay as a deliberate workflow. Treat mock generation as an offline, human-reviewed step, not something that runs in CI:

dev environment → hit sandbox API → log persisted
               → run generator command → fixtures written
               → review diff → commit fixtures → tests replay them

Dev/test-only registration. Register the bundle in ['dev' => true, 'test' => true] only. If it hooks into the HTTP client or kernel events, leaving it enabled in prod means writing request bodies — including credentials — to disk on every call.

Point storage somewhere gitignored. The raw request log is scratch data. Send it to var/request-log/ (or the bundle's configured directory) and add that path to .gitignore. Only the generated mocks should be committed.

If you're integrating with a Laravel codebase, the most practical pattern is to use the bundle's output rather than the bundle itself:

// tests/Feature/ExternalApiTest.php
Http::fake([
    'api.vendor.com/*' => Http::response(
        json_decode(file_get_contents(base_path('tests/fixtures/vendor/orders.json')), true)
    ),
]);

Generate the JSON with the bundle in a Symfony context (or hand-write it once from a real response), then let Laravel's fakes do the replay. You get the same record-then-replay discipline with zero cross-framework coupling.

Wrap fixture lookup in a small helper. As your fixture count grows, a tests/Support/Fixtures::json('vendor/orders') helper keeps test files readable and gives you one place to change when you reorganize the directory.

Isolate recording behind an env flag. If the bundle is active in a shared dev environment, gate it on an explicit REQUEST_LOG_ENABLED=true so a colleague's exploratory poking doesn't overwrite your fixtures.

Gotchas and Tips

The framework mismatch is the headline gotcha. Three stars and zero dependents means nobody has blazed this trail for you, and certainly not in Laravel. Budget time to read the source before assuming any behavior. The bundle is small, so this is measured in minutes, not days — but do it.

Check composer.json version constraints before anything else. A bundle this obscure is likely pinned to Symfony 2.x/3.x/4.x and an older PHP. If your Symfony app is on 6/7 or you're on PHP 8.2+, installation may fail outright or require --ignore-platform-reqs (don't do that on a whim).

Logs capture secrets. Request logs record headers and bodies by default in most implementations of this pattern. Authorization, Cookie, API keys in query strings, and PII in payloads will land on disk. Scrub before committing fixtures, and never let raw logs escape the dev environment.

Fixture drift is the long-term failure mode. Mocked responses silently diverge from the real API. When the vendor changes a field, your tests stay green and production breaks. Mitigate by periodically re-recording against the sandbox and reviewing the diff — ideally on a schedule tied to the vendor's changelog, not on a vague "someday."

Debugging checklist when nothing happens:

1. Is the bundle registered for the current APP_ENV?
2. Did you clear the container cache (bin/console cache:clear)?
3. Is the configured storage directory writable?
4. Is the bundle hooking a specific HTTP client (e.g. Symfony's HttpClient) rather than the kernel — in which case outbound calls made through other clients won't be captured at all?

Extension points. Expect to override the service definitions in src/Resources/config/ rather than subclass anything. Config keys are your primary lever; beyond that, the mock serializer/storage is usually a normal service you can decorate.

Have an exit plan. Low-star, single-maintainer, near-abandoned packages in the request-mocking space are replaceable. Symfony's HttpClient has native mock support and Laravel ships Http::fake() — if you ever need to drop this bundle, the migration is short. Factor that into how deeply you couple to it: keep fixtures in a neutral JSON format you own, not a format only this bundle understands.