Mjr Integration Bundle Laravel Package

Getting Started

Reality check before you install anything: this is a Symfony bundle, not a Laravel package. It will not drop into a Laravel config/app.php providers array. The description says it "provides a low-level integration of MJR into Symfony" — meaning it wires a Modera runtime into the Symfony DI container. As a Laravel developer you either (a) use it inside a Symfony app that sits next to your Laravel service, or (b) read its compiler passes/extension as a reference and reimplement the wiring as a Laravel service provider yourself. There is no Laravel bridge.

Minimal steps if you go the Symfony route:

1. composer require modera/mjr-integration-bundle (be aware the last tag is 2016-06-14 — expect Symfony 2.x/3.0-era constraints and abandoned transitive deps).
2. Register it in app/AppKernel.php (or config/bundles.php on newer Symfony) as new Modera\MjrIntegrationBundle\ModeraMjrIntegrationBundle().
3. Look in this order:
   • ModeraMjrIntegrationBundle.php — what it registers, whether it defines compiler passes.
   • DependencyInjection/ — the extension and its load() method: this is where the real config → service wiring happens.
   • Resources/config/ — the actual service definitions and any tagged services.
   • CompilerPass/ (if present) — where ordering/decorating of MJR services happens.
4. First use case: boot a minimal Symfony kernel with only this bundle plus framework, check php bin/console debug:container for the services it exposes, and confirm they resolve. That's the whole "hello world" — there's no UI, no facade, no route.

Implementation Patterns

Because this is a low-level integration bundle, treat it as glue, not a feature package. Patterns that actually work:

• Container-first usage. You don't call this bundle's API directly; you consume the services it defines. Inject them by ID (or autowire on Symfony ≥3.3 if you patch the config). Get the IDs from debug:container rather than guessing.
• Compose via compiler passes. If MJR requires services to be registered in a specific order or tagged, the bundle will do that in a compiler pass. Your own passes must be added after this bundle's pass (addCompilerPass($pass, PassConfig::TYPE_BEFORE_OPTIMIZATION, -10) etc.) so you see the final service graph.
• Configuration over code. The DI extension exists to map config.yml under the modera_mjr (or mjr) root key into parameters. Read the extension's Configuration class to know the exact keys — they are the contract.
• Bridge pattern for Laravel. If you must share behavior: run the MJR logic in a Symfony micro-kernel or a standalone PHP process, and call it from Laravel via a queued job or an HTTP endpoint. Do not try to load a Symfony bundle inside Laravel's container; the two DI systems don't reconcile.
• Reference implementation. Honestly, the highest-value pattern is to use this repo as documentation for how Modera expects MJR to be wired — copy the extension + compiler pass structure into a ServiceProvider/Singleton in Laravel if you need the same integration.

Gotchas and Tips

• It is effectively unmaintained. 0 stars, 0 dependents, last release 2016. Assume no security patches, no PHP 8 support, and no Symfony 5/6/7 compatibility. Pin your PHP and Symfony versions before composer require, or Composer will fail on abandoned/conflicting constraints.
• No docs, no tests. Your debugging loop is: read source → debug:container --tag=... → lint:yaml / lint:container → cache:clear -vvv. Don't expect a README to save you.
• Service visibility quirks. 2016-era bundles often ship services as public: false or fully-qualified IDs without autowiring aliases. If debug:container shows the service but injection fails, add an alias or a public: true override in services.yml rather than editing vendor code.
• Compiler pass ordering. The classic failure mode with low-level integration bundles is a pass that runs before the services it decorates exist. If MJR services come up empty, reorder your pass with a priority argument — this is usually the whole bug.
• Config key mismatch. The root config key in Configuration::getConfigTreeBuilder() rarely matches the bundle name (e.g. modera_mjr vs mjr_integration). Copy it verbatim from the class; guessing is a common 3-hour rabbit hole.
• Cache is your enemy. Changes to extension/compiler-pass code don't take effect without bin/console cache:clear; in dev, rm -rf var/cache when things look stale.
• Extension points to prefer. If you need to customize behavior, decorate a service (decorates: in YAML) rather than forking the bundle — you leave a clean upgrade path if it's ever revived. Compiler passes are the sanctioned hook; subclassing the bundle rarely works cleanly.
• Fork it in your vendor namespace. Given abandonment, the pragmatic move is to copy the repo into app/Support/Mjr (or your own private package) and pin it there. That gives you PHP 8 fixes and Laravel-friendly service wiring without fighting upstream.