Socom Bundle Laravel Package

Getting Started

Read this first: it is a Symfony bundle, not a Laravel package. mobiledev-pro/socom-bundle ships an MDSocomBundle class, which means it expects a Symfony kernel (bundles.php, the DI container, config/packages/*.yaml). Laravel cannot load a bundle — it has no bundle registration mechanism. Before you invest any time, decide which of these you are doing:

1. You are actually working in a Symfony app → proceed normally.
2. You are in Laravel and need the functionality → you will be cherry-picking classes and wiring them manually through a service provider, not composer require-and-go.
3. You need it as a black box → stand up a small Symfony service and call it over HTTP/queue.

Minimal steps (Symfony path):

composer require mobiledev-pro/socom-bundle

// config/bundles.php
return [
    // ...
    MobileDev\SocomBundle\MDSocomBundle::class => ['all' => true],
];

Then confirm what you actually got before configuring anything:

composer show mobiledev-pro/socom-bundle   # version, requirements, autoload
bin/console debug:config mdsocom           # is there a config tree at all?
bin/console debug:container --tag=socom    # any tagged services?

Where to look first, in this order:

• composer.json — the require block tells you which Symfony major it was built against and whether it pulls in HTTP clients, Doctrine, etc. This is the single most important file given the package's age and lack of dependents.
• DependencyInjection/Configuration.php — the real API surface. If there is no Configuration class, the bundle takes no config and is probably a thin wrapper or a set of hardcoded services.
• DependencyInjection/MDSocomExtension.php — reveals whether services load unconditionally or behind a flag.
• Resources/config/ — actual service definitions, parameters, and any hardcoded hosts/URLs.
• The README, last. With zero stars and a "specific needs of MobileDev" description, the README is likely a stub; the code is the documentation.

Your first use case should be the narrowest one available: instantiate the bundle's main service in a scratch command and confirm it resolves from the container and reaches whatever upstream it talks to. Do not wire it into a request path until you have seen a successful round-trip in isolation.

Implementation Patterns

Prefer constructor injection over container lookups. Because bundles register services into the Symfony container, the clean pattern is to type-hint the bundle's service interface in your own services and let autowiring resolve it. Resist $container->get('mdsocom.something') — string service IDs in a low-traffic package are exactly the kind of thing that gets renamed between patch releases.

Configure via the bundle's own tree, and keep it environment-scoped.

# config/packages/mdsocom.yaml
mdsocom:
    # keys come from the bundle's Configuration.php — do not guess
    base_uri: '%env(SOCOM_BASE_URI)%'
    token: '%env(SOCOM_TOKEN)%'

# config/packages/test/mdsocom.yaml
mdsocom:
    base_uri: 'http://localhost:8081'

Put credentials in .env / secrets, never in the committed YAML. If the bundle has no config tree, its parameters are set via parameters: in your own services.yaml — check the extension class for %mdsocom.*% placeholders.

Adapter pattern for the Laravel side. If you must consume this from Laravel, do not try to boot the bundle. Instead:

• Require the package for its classes only.
• Write an MdSocomServiceProvider that binds the underlying client/service as a singleton, passing config from config/services.php.
• Wrap every call behind your own interface (SocomGateway) so the bundle's concrete classes never leak into controllers or jobs.

$this->app->singleton(SocomGateway::class, fn ($app) => new BundleBackedSocomGateway(
    new \MobileDev\SocomBundle\Service\SocomClient(
        config('services.socom.base_uri'),
        config('services.socom.token'),
    ),
));

The constructor signature above is illustrative — read the actual class before writing this. The point is that the seam lives in your codebase, not in vendor.

Extension points. For a bundle this small, assume there are no designed extension points. The realistic ones are Symfony's generic mechanisms:

• Decoration — decorates: mdsocom.client in services.yaml to wrap the bundle's service with logging, retries, or caching.
• Tagged services — if debug:container --tag= reveals a tag, that is a deliberate collection point; add your own implementations to it.
• Compiler pass — only worth it if the bundle exposes parameters you cannot override otherwise.

Testing. Use KernelTestCase and pull the service from the container in a setUp(); for anything hitting the network, bind a mock over the service ID in config/services_test.yaml rather than mocking deep inside the bundle.

Gotchas and Tips

The support signal is the headline risk. Zero stars, zero dependents, and a description that literally says "specific needs of MobileDev" means: no issue triage, no security response, no upgrade path, and a real chance the maintainers consider the public API whatever their own app happens to call. Treat it as internal vendor code that leaked into public.

Pin it exactly and vendor it. Use an exact version constraint ("mobiledev-pro/socom-bundle": "1.2.3"), commit composer.lock, and consider forking into a private VCS repo you control. A bundle with no dependents can be force-pushed, retagged, or abandoned without anyone noticing.

Version drift is your most likely failure mode. Last release was August 2024. A Symfony bundle pins to a framework major via symfony/framework-bundle and symfony/dependency-injection constraints. Check those against your app: on Laravel 11 you are already on Symfony 7 components, so if the bundle requires ^5.4|^6.0, it will not load in a Symfony 7 kernel and its classes may carry signatures that clash. composer why-not is faster than debugging a container error.

The bundle must be registered in bundles.php. A classic first-day mistake: install the package, then wonder why nothing autowires. In Symfony, unregistered bundles contribute no services. In Laravel there is no equivalent — nothing autowires at all, which is why the adapter path above is mandatory.

Autoconfiguration may not cover it. Small bundles often define services explicitly in YAML/XML without autoconfigure: true, so your decorators and tagged implementations will not be picked up automatically. Declare tags explicitly on your side.

Hardcoded internals are likely. Given the description, expect hardcoded base URLs, staging hosts, timeouts, or log channels inside Resources/config/. Grep before trusting config:

grep -rn "http" vendor/mobiledev-pro/socom-bundle/Resources/config/
grep -rn "getenv\|_ENV\|%mdsocom" vendor/mobiledev-pro/socom-bundle/

Anything you find hardcoded is a fork candidate.

Debugging playbook, in order:

bin/console lint:container                      # catches bad service args early
bin/console debug:config mdsocom                # shows resolved config after your YAML
bin/console debug:container MobileDev\\Socom    # confirms the service exists and is public/private
bin/console debug:event-dispatcher | grep -i socom

If the bundle registers listeners or subscribers, debug:event-dispatcher is the only way you will find them — a package that quietly hooks kernel.request can be very confusing to debug from the Laravel side, where those events never fire.

Isolate it behind your own interface on day one. Even in pure Symfony, wrap the bundle's services. Bundle APIs from unmaintained packages churn; three call sites deep in controllers is a refactor, one interface is a swap. This is the single highest-leverage thing you can do regardless of which path you chose.

Budget an exit. Before adopting, answer: what does this package do that is genuinely hard? A small HTTP client wrapper is a day's work to replace. If the answer is "not much," skip the dependency entirely — a zero-star, zero-dependent, "for our specific needs" bundle is a liability with a maintenance bill attached.