Larping Bundle Laravel Package

Getting Started

Confirm what you actually have before you install anything. larping-base/larping-bundle is packaged as a Symfony bundle (type: symfony-bundle in its composer.json, *Bundle class under src/), not a Laravel package. There is no LarpingBundleServiceProvider, no extra.laravel.providers, and Laravel's package discovery will ignore it. If you are in a Laravel app, you have three options: (a) don't use it, (b) pull it in as a standalone library if the gateway classes have no container dependencies, or (c) bridge it with a hand-written service provider that binds its services manually. Decide this before writing code.

First five minutes, in order:

1. composer show larping-base/larping-bundle — check type, require, and whether symfony/framework-bundle / symfony/http-client are pinned to versions compatible with your stack.
2. Open composer.json in the repo and read extra.symfony and the require block. This tells you the minimum Symfony version and which HTTP client abstraction it expects.
3. Read src/DependencyInjection/*Extension.php and Configuration.php. These are the ground truth for every config key — the README (if any) is likely thinner than the code.
4. Skim the *Bundle class build() / load() methods for compiler passes and tagged services. Tagged services are the usual hidden extension point in gateway bundles.
5. Only then install.

Install and register (Symfony host):

composer require larping-base/larping-bundle

// config/bundles.php
return [
    // ...
    LarpingBase\LarpingBundle\LarpingBundle::class => ['all' => true],
];

First use case: wire the gateway into one service and hit it in a console command before touching HTTP controllers. Gateways are I/O boundaries — you want to see the request/response shape in bin/console output, not behind a browser. Inject the gateway service (find its ID with bin/console debug:container --show-private | grep -i larping), call its single public entry point, dump the result.

If there is no usable README, you are reverse-engineering from src/. Budget for that.

Implementation Patterns

Treat the bundle as an adapter, not as your domain. The description ("Common Gateway bundle") suggests it wraps outbound calls behind a shared interface. Wrap it again in your own port so your application never imports LarpingBase\* directly:

interface PaymentGateway
{
    public function charge(string $reference, int $amountMinor): Receipt;
}

final class LarpingPaymentGateway implements PaymentGateway
{
    public function __construct(private readonly \LarpingBase\LarpingBundle\Gateway $gateway) {}
    // map domain -> bundle DTOs, catch bundle exceptions -> your exceptions
}

This is the single highest-value pattern here. With 1 star and 0 dependents, the public API is effectively guaranteed to move; the wrapper is five lines and buys you a rewrite-free upgrade path.

Configuration-driven setup. Create config/packages/larping.yaml and mirror the tree from Configuration.php exactly. Symfony's config tree is strict — unknown keys throw InvalidConfigurationException at container compile time, which is actually a good thing: you find typos at cache:clear, not at runtime. Use env vars for secrets:

larping:
    base_uri: '%env(LARPING_BASE_URI)%'
    credentials:
        key: '%env(LARPING_KEY)%'

Profile-based instantiation. If the bundle exposes multiple gateway backends (sandbox vs. live), bind the choice via a service alias per environment rather than if (env === 'prod') inside your services. Aliasing in services.yaml under when@dev / when@prod keeps the branching in the container, where it's cheap and inspectable.

Testing. The gateway almost certainly takes an injected HTTP client (PSR-18 or Symfony HttpClientInterface). In test config, decorate or alias it to MockHttpClient:

# config/services_test.yaml
services:
    LarpingBase\LarpingBundle\Http\Client: '@http_client.mock'

Then your integration tests assert on the outbound request body rather than mocking your own wrapper — you get coverage of the bundle's serialization, which is where gateway bugs actually live.

Laravel bridging, if you go that route. Register a provider that mirrors the bundle's Extension::load(): read config('larping.*'), bind() each service definition manually, and map the bundle's exception hierarchy onto Laravel's. Do not attempt to boot the Symfony bundle inside Laravel — Bundle::boot() expects a ContainerInterface with set()/compile() semantics and a KernelInterface you don't have.

Gotchas and Tips

License is NOASSERTION. This is the blocker, not a footnote. No declared license means no granted rights — have legal sign off before this ships to production, and before you copy any of its code patterns. If this is commercial software, stop here.

Zero dependents, one star, one release (2024-03-22). Assume no maintainer response time and no upgrade path. Pin the exact version ("larping-base/larping-bundle": "1.0.0" not "^1.0"), commit composer.lock, and read the source of anything you depend on. There is no ecosystem to Google when it breaks.

Bundle autodiscovery does not exist. Laravel devs are used to composer require just working. Here you must edit config/bundles.php and config/packages/*.yaml by hand, and cache:clear after every config change or the container serves stale definitions.

Debugging container wiring:

bin/console debug:container --tag=<tag-from-bundle-build>
bin/console debug:config larping
bin/console lint:container

debug:config prints the resolved tree with defaults — the fastest way to learn which keys are real when docs are absent. lint:container catches type mismatches in injected services before runtime.

Extension points, in rough order of stability:

• Compiler passes — if the bundle collects tagged services, this is your hook for registering custom handlers without forking.
• Service decoration — the cleanest way to intercept a gateway call (logging, retries, metrics) without touching bundle code. Decorate the concrete class ID, not an alias.
• Event dispatcher — if the bundle dispatches pre/post-call events, prefer subscribers over decoration; less coupled to class names.
• Forking — with one release and no license clarity, forking may be the honest answer. If you fork, vendor it under your own namespace and delete the original dependency.

Watch for a global HTTP client dependency. Gateway bundles frequently require a specific client (symfony/http-client or Guzzle). If it conflicts with what your app already uses, Composer will either fail or you'll end up with two clients and two sets of timeout/retry semantics. Check composer why symfony/http-client after install.

Timeouts and retries are yours to set. Gateways rarely ship sane defaults for your traffic profile. Set explicit connect/read timeouts and idempotency-safe retries at your wrapper layer, not by hoping the bundle does it.

No tests in the repo? Assume none. Verify before you trust edge-case behavior (empty responses, 429s, malformed JSON). Write characterization tests against the real gateway in a sandbox environment and commit them — they become your upgrade contract.