Mandango Bundle Laravel Package

Technical Evaluation

Architecture fit — a category error that must be corrected before any estimate is given. The score of 0.999 is a semantic-similarity artifact, not a fitness signal. mandango/mandango-bundle is a Symfony2 bundle: a MandangoBundle class, a DependencyInjection/MandangoExtension.php, YAML configuration under the mandango key, and mandango:generate console commands. Laravel's container, config repository, and Artisan consume none of that. There is no Illuminate\Support\ServiceProvider, no facade, no publishable config, no package discovery entry. Dropped into a Laravel codebase the bundle is inert. Only the upstream mandango/mandango core library is theoretically callable — and only if you hand-write the connection wiring, the metadata loading, and the model generation yourself, which is precisely the work the bundle exists to do for Symfony.

Integration feasibility — very low, and the honest answer is that "integration" is the wrong framing. Mandango is a code-generating ODM: you author XML/PHP schema definitions, run Mondator at build time to emit model, repository, and query classes, then consume those generated classes through a connection/unit-of-work API. There is no Eloquent analogue. Adopting it means running a second, parallel persistence paradigm beside Eloquent, with its own codegen stage in CI and its own generated artifacts under version control. The bundle's sole value-add — Symfony DI wiring for that codegen — is the one piece Laravel cannot reuse. Net: you would be porting the integration, not installing it.

Technical risk — critical, with at least three independent disqualifiers, any one of which is sufficient:

• Runtime. Mandango targets the legacy ext-mongo extension (MongoClient/MongoCollection), removed in PHP 7. The replacement ext-mongodb has an incompatible API. This is a driver-layer rewrite, not a patch.
• Lifecycle. Symfony 2.x went EOL in 2018; Mandango has been unmaintained for roughly a decade. No security patches, no PHP compatibility work, no upstream triage.
• Ecosystem. 25 stars, 0 dependents. No installed base, no community knowledge, no third party validating it against any current toolchain.

Key questions for the requester:

1. Is there an existing Symfony2 application in the estate already running Mandango, or is this greenfield in Laravel? The answer flips the recommendation entirely.
2. What is the actual requirement — "MongoDB persistence in Laravel," or specifically Mandango's codegen/query API? If the former, this package is simply the wrong answer.
3. What PHP version is the target runtime? At ≥7.0 the package is unusable as shipped; state this before effort is estimated.
4. Is production data already stored in a Mandango-managed schema (embedded documents, _id conventions)? That determines migration scope, not adoption scope.
5. Who owns codegen in CI today, if anyone? An unowned build step is a silent-failure risk.

Integration Approach

Stack fit — none for Laravel, and I would not fund a compatibility spike without a named business justification. The supported path for MongoDB from Laravel is ext-mongodb plus the official mongodb/mongodb driver, on top of either mongodb/laravel-mongodb (preserves Eloquent idioms, near-zero ramp-up) or doctrine/mongodb-odm (document-mapper style). Both are maintained, PHP 8 compatible, and staffable. Mandango offers nothing these do not, and lacks everything they do.

Recommendation: decline the bundle and scope a substitute. Three scenarios, three answers:

• Greenfield Laravel + MongoDB: reject outright. Adopt mongodb/laravel-mongodb. The decision is a one-line architecture standard, not a project.
• Legacy Symfony2 app already on Mandango: freeze it. Pin exact versions, vendor dependencies, and do not attempt to lift the bundle into Laravel. Fund an exit plan: export via the modern driver, remodel in the target layer, cut over read paths before write paths.
• Data-only migration: a one-time ETL script against mongodb/mongodb is a matter of days and retires the dependency permanently. This is usually the cheapest credible option and should be the default proposal.

Compatibility. Assume incompatible until a spike proves otherwise, and verify in this order: (a) installs at all under target PHP; (b) ext-mongo exists in the runtime image; (c) generated codegen output parses under target PHP; (d) connection layer talks to the target MongoDB server version. Expect failure at (b). Timebox the spike to 1–2 days with a written kill criterion — do not let it become a research project that quietly consumes a sprint.

Sequencing, only if a spike succeeds and a justification exists. (1) Isolate behind an interface in a single bounded module; (2) run codegen as an explicit, auditable build step with generated output committed and diff-reviewed; (3) wrap the connection in a service provider you own, since the bundle supplies none; (4) forbid the Mandango API from leaking into domain code; (5) set the retirement date at kickoff, not later. Given the risk profile, step 1 should not start without a business reason the maintained alternatives cannot satisfy.

Operational Impact

Maintenance — orphaned by construction. No upstream will fix a CVE, a PHP deprecation, or a MongoDB server break. Every runtime upgrade becomes archaeology against dead code, and the team inherits full ownership of a codebase with no external expertise anywhere. For a TPM this is a permanent, unbounded liability on the roadmap: the item that quietly consumes a sprint every time the platform bumps a version. This is the dominant cost, not licensing — MIT is fine.

Support and hiring. Zero dependents and 25 stars means no Stack Overflow corpus, no blog posts, no contractors, no internal peers to consult. Onboarding an engineer to Mandango's codegen-plus-unit-of-work model is bespoke training with no transferable market value. If the one person who understands it leaves, you have a single point of failure with no market remedy — you cannot hire your way out of it.

Scaling. Mandango's design predates modern connection-pooling, retry, and topology conventions; you own pooling, read/write concern configuration, transactions (needing MongoDB 4.0+ and driver capabilities the library cannot express), and observability hooks yourself. Past modest throughput this stops being configuration and becomes standing engineering work — a recurring cost line that never appears in the initial estimate.

Failure modes to plan for. (1) Hard install failure on PHP ≥7 — the most likely outcome, surfacing immediately and cheaply. (2) Silent codegen drift — generated classes diverge from source definitions, producing subtle query bugs. (3) Extension removal in a base-image rebuild, breaking deploys with no code change and no warning. (4) Server-version incompatibility — a managed MongoDB upgrade breaks the client with no upstream fix. (5) Bus factor on team turnover. (6) Audit/security finding — a scanner flags an EOL dependency and forces migration under deadline pressure, at the worst possible moment. Only (2) has a real mitigation (committed generated output plus CI diffs); (1), (3), and (4) have none short of replacement.

Ramp-up. A Laravel team needs roughly 2–4 weeks to reach marginal productivity on Mandango's codegen and query model, plus the same again for the legacy Symfony wiring if a legacy app is in scope — versus 2–3 days for mongodb/laravel-mongodb given existing Eloquent fluency. That delta, compounded annually by the maintenance tax above, is the whole business case.

Bottom line for the roadmap. Do not adopt for Laravel; close the request and substitute mongodb/laravel-mongodb if MongoDB is the genuine requirement. If a legacy Symfony2/Mandango system exists, fund a timeboxed exit plan rather than any new integration work. Either way, register the package as end-of-life technology in the dependency register with a named owner and a target retirement date — the deliverable here is a decision and a dated exit, not an integration.