Lendo Infrastructure Bundle Laravel Package

Getting Started

This is an internal infrastructure bundle maintained by Lendo STP Gdańsk. With zero public stars and no dependents, treat it as an organization-specific package rather than a community library — the README and the service provider are your real documentation.

1. Install and inspect before wiring anything up.

   composer require lendo-stp-gdansk/lendo-infrastructure-bundle
   

   Then immediately read what Composer actually pulled in:

   composer show lendo-stp-gdansk/lendo-infrastructure-bundle
   ls vendor/lendo-stp-gdansk/lendo-infrastructure-bundle
   

   Check composer.json for extra.laravel.providers (auto-discovery) versus a Symfony-style DependencyInjection/*Extension.php. The package name says "bundle," which usually implies Symfony conventions; confirm whether it exposes a Laravel ServiceProvider at all before assuming php artisan vendor:publish will work.

2. Look first at these files, in order:

   • README.md — the only usage contract that exists.
   • src/*ServiceProvider.php (or DependencyInjection/) — what gets bound, tagged, or registered.
   • config/ — every key you're expected to fill in.
   • CHANGELOG.md / tags — how actively it moves and whether breaking changes are frequent.

3. First use case: standardize cross-cutting concerns across services. Infrastructure bundles typically own logging channels, health/metrics endpoints, HTTP client defaults (timeouts, retries, correlation IDs), queue/worker config, and shared base classes. Start by adopting one of those — usually the health endpoint or the HTTP client — rather than enabling everything at once. That gives you a reversible slice and a fast signal on whether the package fits.

Implementation Patterns

Configuration-first registration. Publish and diff the config rather than relying on package defaults:

php artisan vendor:publish --provider="Lendo\Infrastructure\InfrastructureServiceProvider" --tag=config

Then commit the published file so environment drift is visible in review. For a Symfony-style bundle, the equivalent is importing the bundle's service definition and overriding parameters in config/services.yaml.

Wrap the package behind your own adapter. Since the package is internal and unversioned in practice, isolate it:

// app/Infrastructure/HealthProbe.php
final class HealthProbe
{
    public function __construct(private readonly LendoHealthClient $client) {}

    public function check(): array
    {
        return $this->client->report(); // single seam to swap out later
    }
}

Bind it in a small app-level provider. If the bundle is ever deprecated or diverges from your service's needs, you change one class instead of hunting usages.

Environment-driven config, not code branches. Infrastructure bundles almost always read env on boot. Keep every knob in config/infrastructure.php mapped to an env() call, and set those per-environment in your deploy config (not in .env committed to the repo). Typical culprits: log level, sampling rate, external endpoint URLs, timeout values, and feature flags.

// config/infrastructure.php
return [
    'http' => [
        'timeout' => env('INFRA_HTTP_TIMEOUT', 3),
        'retries' => env('INFRA_HTTP_RETRIES', 2),
        'base_url' => env('INFRA_BASE_URL'),
    ],
    'health' => [
        'enabled' => env('INFRA_HEALTH_ENABLED', true),
        'path' => env('INFRA_HEALTH_PATH', '/_health'),
    ],
];

Integration points to check explicitly.

• HTTP client: confirm whether the bundle decorates Laravel's Http facade or ships its own client. If it decorates, correlation-ID propagation happens automatically; if it ships its own, you must inject it everywhere and Http:: calls silently bypass it.
• Logging: verify whether it pushes a handler onto the default channel or defines a new channel. Mixing both produces duplicate log lines.
• Queues: shared worker middleware (job tagging, tenant context) is a common bundle feature — confirm it's registered on your queue connections, not just the default one.
• Migrations: if the bundle ships migrations, register its path in a provider rather than copying files, so upgrades carry schema changes.

Testing pattern. Use Laravel's RefreshDatabase plus an explicit config reset for bundle keys, and stub any external infrastructure calls with Http::fake():

protected function setUp(): void
{
    parent::setUp();
    config(['infrastructure.health.enabled' => false]); // keep tests offline
    Http::fake(['*' => Http::response(['status' => 'ok'], 200)]);
}

If the bundle binds singletons that hold state (clients, buffers), assert on behavior through the adapter, not by reaching into the container.

Gotchas and Tips

• No stars, no dependents, score 0. This is an internal package with no public signal. Before adoption, confirm with the Lendo STP Gdańsk team: is it maintained, what's the versioning policy, and who owns it? If you can't get a maintainer name, don't put it on a critical path.
• "Bundle" in the name is a red flag for Laravel. Verify the package actually ships a Laravel ServiceProvider. Symfony bundles need config/bundles.php and won't auto-discover. If it's Symfony-flavored, plan on a thin bridge or skip it in a Laravel app.
• Auto-discovery can mask missing config. Laravel registers the provider even when required env vars are absent — the failure surfaces later as a 500 on a background job. Add a boot-time assertion for required keys in non-local environments.
• Silent config caching. After any bundle config change, run php artisan config:clear. Infrastructure bundles often read config in register() rather than boot(), so stale caches produce baffling behavior where "the env var is set but nothing changed."
• Duplicate log handlers. If the bundle registers a Monolog handler and you've added one for the same channel, you'll see doubled entries and skewed sampling. Dump the resolved logger config with Log::getLogger()->getHandlers() when in doubt.
• Health endpoint collisions. Infrastructure bundles love /_health and /health. If your app or load balancer already defines one, you'll get a route conflict or, worse, two endpoints answering differently — one checking the DB, one not. Grep your routes with php artisan route:list | grep -i health.
• Extension points worth using. Most bundles expose interfaces for the pieces you're likely to override — client factories, health checkers, context providers. Prefer binding your own implementation of the interface over extending concrete classes; concrete classes are the first thing to change in a major bump.
• Version pinning. With no dependents, there's no crowd to catch a bad release. Pin to an exact version ("1.2.3", not "^1.0") and upgrade deliberately with the changelog open.
• Debugging checklist when it misbehaves: composer why lendo-stp-gdansk/lendo-infrastructure-bundle → confirm it's discovered (php artisan about shows providers) → confirm config resolved (config('infrastructure')) → confirm container bindings (app()->bound(...)) → then trace the actual call path. Most "bundle is broken" reports are config precedence.
• Have an exit plan. Because this package has no community, write the adapter seam on day one (see Implementation Patterns) and keep a note of every bundle feature you depend on. Migrating off a small internal package is trivial with a seam and painful without one.