Mjr Integration Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for MJR connectivity: this bundle is evidence that a pre-built integration path once existed, but it is a 2016-era Symfony bundle published as a [READ-ONLY] archive with zero stars and zero dependents. It supports a buy/reuse decision only as a negative data point — the realistic options are "adopt the vendor's current SDK/API" or "build a thin in-house adapter."
• Framework-fit validation: the package is a Symfony bundle, not Laravel. Any roadmap item scoped as "use the Modera MJR package in our Laravel app" is mis-scoped at the architecture level; that alone is worth surfacing before estimation.
• Legacy dependency triage: useful as an input to audit decisions — "do we keep, fork, or replace abandoned integrations in our composer.lock?" Answer here is almost always replace, since the code has had no release since 2016-06-14 and no downstream dependents.
• Feature scoping for MJR-dependent capabilities: if MJR underpins a planned feature (reporting, data sync, whatever the business unit expects), this package lets you inspect the shape of the integration contract (client wiring, DI configuration, endpoints) without committing to it — a cheap way to de-risk an estimate.
• Due diligence / M&A or vendor review: "single unmaintained integration, zero community, archived repo" is a concrete finding to log when assessing technical debt or supplier risk.
• Support & compliance gating: informs the decision to gate any MJR feature behind a security review, since an unmaintained 2016 PHP dependency will not receive patches and may conflict with modern PHP/Symfony constraints.

When to Consider This Package

Consider it only when all of the following hold:

• You are running a Symfony application (2.x/3.x era) that already integrates with MJR and you need to understand or document the existing contract.
• You are doing archaeology, not adoption — reading the source to extract endpoint shapes, auth expectations, and payload models, then reimplementing them.
• You need a reference for the protocol, not a runtime dependency, and you're comfortable pinning nothing to it.
• The MJR vendor has no current SDK and you need a starting point to write a minimal adapter yourself.

Look elsewhere — or stop — when:

• The stack is Laravel or any non-Symfony framework. This is the wrong artifact; there is no portability here.
• You need PHP 7.4+/8.x compatibility, PSR-compatible HTTP clients, or maintained DI wiring. A bundle last released in 2016 will fight modern Symfony.
• You require a support SLA, security patching, or a CVE response path. Zero stars, zero dependents, archived — there is no maintainer and no community.
• Adoption volume matters. With zero dependents, you would be the only consumer; every bug is yours to fix.
• You're on a deadline. Debugging a decade-old integration is strictly slower than writing a small, testable client against the vendor's documented API.

How to Pitch It (Stakeholders)

Executive summary: We evaluated modera/mjr-integration-bundle, a Symfony bundle that provides low-level MJR integration. It is archived, read-only, has had no release since June 2016, and has zero stars and zero dependents. Recommendation: do not adopt it as a dependency. It carries the full cost of ownership — security patching, framework compatibility, and bug fixes — with none of the community or vendor support we'd normally rely on to offset that cost.

What it's still good for: a free look at the MJR integration surface. Reading the source gives us the endpoint contract and payload shapes at effectively zero cost, which sharpens our estimate for building a small adapter ourselves.

Business risk if we adopted it:

• Security/compliance: unmaintained code from 2016 will not receive fixes; likely fails a modern dependency review.
• Delivery risk: incompatible with current PHP/Symfony versions; expect unbounded debugging time.
• Key-person risk: no maintainer, no community, no upstream path — we would own it forever.
• Framework mismatch: it is a Symfony bundle; any plan assuming it drops into a Laravel codebase should be corrected now.

Ask: approve a short timeboxed spike (1–2 days) to read the bundle, extract the MJR contract, and confirm the vendor's current API/SDK. Engineering then implements a thin adapter behind our own interface so the integration stays swappable. Finance/procurement should confirm whether an MJR vendor support agreement exists — if it does, use the vendor's supported client and close this out. If neither path is viable, the honest option is to descope the MJR-dependent feature rather than adopt a ten-year-old abandoned integration.