Languages Bundle Laravel Package

Technical Evaluation

Architecture fit. The decisive finding for any TPM scoping this is that modera/languages-bundle is not a Laravel package despite the catalog framing — it is a legacy Symfony bundle from the Modera CMS platform, published as a read-only subtree split of an internal monorepo. Its architecture assumes a Symfony kernel, the dependency-injection container and compiler passes, Doctrine ORM entity mapping, and Modera foundation base classes. Laravel's service-provider model, Eloquent, and its own container are structurally different. Nothing here would function after a composer require.

Integration feasibility. Low, and the effort is misallocated. There is no service provider, no publishable config, no migration set, and no facade. A Laravel integration would require booting a Symfony bundle inside Laravel via a custom bridge, standing up Doctrine alongside Eloquent, and reconciling entity mappings with Laravel's hydration model. That bridge would be an order of magnitude larger and riskier than the domain problem it solves, which is "store a list of languages with ISO codes, display names, and an enabled flag" — roughly 200 rows of static reference data behind a trivial lookup API.

Technical risk. High and concentrated in dependency resolution. A mid-2016 release carries PHP and Symfony 2.x/3.0-era constraints, while Laravel 10/11 pull Symfony 6/7 components transitively. Composer will almost certainly fail to resolve, forcing one of three bad options: --ignore-platform-reqs (green build, unverified runtime), a fork with rewritten constraints (we now own it), or exclusion of transitive dependencies (undefined behavior). Secondary risk vectors: unpatched advisories in abandoned transitive dependencies that can block release pipelines; zero dependents, meaning no field evidence the package works anywhere; two stars, meaning no community review; and a read-only mirror with no upstream destination for issues or PRs. The composite score of 0.01 against an opportunity score of 23.62 is the signal in one line — a genuine, recurring problem space with no viable incumbent. That points to build, not buy.

Key questions.

• What is the actual product requirement? If it is "manage a configurable language list and set the application locale," this is a one-to-two-day Laravel-native build, not an integration project.
• Does the Modera platform upstream still track this code, and can we obtain a security-patch commitment or a license that permits a private fork?
• Is the value in the shipped code, or in the data model and locale-negotiation semantics? If the latter, the repository is a specification, not a dependency.
• Which PHP and Symfony versions are actually declared in composer.json, and does that survive a Laravel 11 install?
• Does a maintained alternative already cover this transitively — symfony/intl / PHP's Intl extension with CLDR data — such that the requirement is already satisfied at zero marginal cost?

Integration Approach

Stack fit. Poor as a runtime dependency, credible as a reference implementation. The conceptual surface — a language record with ISO code, locale, display name, enabled/disabled state, and retrieval-by-code — maps cleanly onto an Eloquent model plus a small service class. That mapping is the deliverable; the shipped PHP is not.

Migration path. Recommended: source-code archaeology followed by native reimplementation.

1. Read the repository as documentation. Catalog fields, indexes, uniqueness constraints, ordering, enabled-state filtering, and any default-language or fallback negotiation behavior.
2. Reimplement as a Laravel migration plus an Eloquent model, with a cached LanguageRepository and a SetLocale middleware performing negotiation against Accept-Language.
3. Deliberately do not port Doctrine entities, Symfony forms, or bundle DI configuration — those carry all the integration cost and none of the business value.
4. Source the language names from symfony/intl (Languages::getNames()) or a maintained list package rather than hand-curating them.
5. Ship behind an interface so any future swap is a container binding, not a rewrite.

If a hard requirement exists to run the original code, the only viable route is a private fork with modernized composer.json constraints, a Doctrine bridge, and a Symfony bundle bootstrapper registered from a Laravel service provider. Budget that as a multi-week spike with an explicit kill criterion — not as an integration task.

Compatibility. The declared PHP and Symfony constraints are the single check that decides whether the fork path is hours or weeks; run it before anything else. Also confirm Doctrine's naming-strategy assumptions against Laravel's snake_case conventions if pointing an Eloquent model at existing tables is in scope for data migration.

Sequencing. (1) Constraint and license audit — half a day, gates everything. (2) Requirements extraction from source — one day. (3) Native schema, model, repository, cache — one to two days. (4) Middleware and locale negotiation. (5) Admin/CRUD surface if required. (6) Backfill from any existing table. Total for the recommended path: one to two engineering days versus one to three weeks for fork-and-bridge.

Operational Impact

Maintenance. This is a total ownership transfer. Upstream is a read-only mirror with no release since June 2016, so every bug, PHP upgrade, and security patch becomes ours. A forked dependency of this vintage is a permanent line item in the maintenance budget, and the cost is disproportionate here specifically because the code volume is modest — owning a fork of something this small is hard to justify economically against simply owning a replacement.

Support. Effectively none. Two stars and zero dependents means no issue history to search, no Stack Overflow corpus, and no community escalation path. Any internal Modera documentation will describe the CMS context, not Laravel usage. Escalation is "read the source," which requires a developer fluent in Symfony 2.x idioms.

Scaling. A non-issue, and worth saying so explicitly so it does not consume review time. The dataset is tiny and read-mostly; the whole table belongs in a process-local or Redis cache invalidated on write. There is no throughput concern at any realistic scale. The only real risk in this dimension is correctness under cache staleness, not load.

Failure modes.

• Composer resolution failure at install and on every future composer update — most likely and most frequent.
• Doctrine/Eloquent impedance producing silent data-shape mismatches.
• Locale fallback errors surfacing as untranslated UI or wrong-language transactional emails — customer-visible and easy to miss in test coverage.
• Security scanning flagging abandoned transitive dependencies and blocking release pipelines.
• PHP minor-version upgrades breaking the fork with no upstream fix path.
• Bus factor of one: whoever builds the Symfony bridge holds the only working knowledge.

Ramp-up. Reading the package demands Symfony familiarity a Laravel team typically lacks — budget roughly a day of orientation just to interpret bundle conventions, compiler passes, and Doctrine mappings. The native reimplementation is junior-friendly once the schema is settled. Net recommendation: build native, cite modera/languages-bundle as the design reference, and record the abandoned-dependency decision in the architecture log so the next team does not reopen the buy-versus-build question from scratch.