Mjr Theme Integration Bundle Laravel Package

Technical Evaluation

Architecture fit. The critical fact a TPM needs before any planning: this is a Symfony bundle, catalogued here as a Laravel/PHP package. The *Bundle suffix is the tell. It wires the MJR (Modera) ExtJS admin theme — compiled JS/CSS assets, Twig layout partials, and a DependencyInjection extension — into a Symfony kernel. It has no service provider, no facade, no config/*.php publish tags, and no Blade views. Against our Laravel stack the impedance is total, not a matter of minor adaptation. Even on Symfony its value is glue; the substance (theme SCSS/JS, ExtJS overrides, layout templates) lives in published assets, and the actionable source is a [READ-ONLY] monorepo split of unknown vintage. This is a roadmap input, not an integration candidate.

Integration feasibility. Low as a Composer dependency; moderate only as an asset quarry. A 2016-era constraint set (PHP 5.5+, Symfony 2.8/3.x, sibling Modera bundles pinned to the same window) will not resolve against PHP 8.x, and --ignore-platform-reqs only moves the failure to runtime. The realistic path is reading the repo as reference — extract theme assets, understand the ExtJS overrides, and re-home the container/config glue idiomatically if we want any of it. This is a port, not an install.

Technical risk. High across every dimension that matters to a PM:

• Abandonment. Zero stars, zero dependents, score 0, last release 2016-06-10, explicitly read-only. No issue triage, no security backport, no PHP-version upkeep. For anything touching an admin surface, this is disqualifying on its own.
• Stale snapshot risk. The maintained source of truth is the Modera monorepo. This split may be years behind it, so we would be inheriting an unknown-vintage mirror.
• Licensing exposure. ExtJS is a commercially licensed Sencha product. Shipping its runtime or theme without a current Sencha agreement is a legal risk that dwarfs the technical one, and Sencha's terms have changed materially since 2016.
• Skills scarcity. ExtJS 4/5-era patterns (Ext.define, class system, layout managers) are a niche skillset. Hiring and code review are both expensive, and we have no internal depth on record.

Key questions for the team.

1. Is an ExtJS/MJR admin actually a product requirement, or did a keyword search surface this? If the former, what is the migration-off-ExtJS horizon?
2. Do we hold a valid Sencha/ExtJS license covering redistribution?
3. Is the upstream Modera monorepo active, and does it contain a modernized version of this integration?
4. What do we actually want — theme SCSS/JS assets, layout templates, or the container wiring? Only the first two are plausibly reusable.
5. Are we willing to fork and own this permanently, including PHP-version upkeep and security patching?

PM decision: No adopt. This is a low-stakes call, not a trade-off. Log it as Hold/Avoid on the tech radar so the next person does not rediscover it.

Integration Approach

Stack fit. Poor vs. Laravel (no service provider, no publish tags, no Blade), weak vs. modern Symfony, acceptable only as a static asset source. Every viable path is a salvage operation, and the TPM's job is to keep the scope from drifting into "just make it work."

Migration path — frame as a one-time extraction, not a dependency.

1. Audit the repo — inventory Resources/ (public assets, Twig templates, SCSS), DependencyInjection/ (which config knobs exist), and composer.json (exact transitive assumptions). Confirm whether assets are originals or references into the monorepo.
2. Extract, don't resolve — copy theme assets into our own resources/ tree. Do not add the bundle to composer.json. Vendor-pinning abandoned code creates upgrade deadlock we would own forever.
3. Re-home the glue — translate container/config wiring into a Laravel service provider or, better, a thin config file plus a Blade/Twig layout wrapper.
4. Replace the asset pipeline — the bundle predates Vite/Mix conventions. Run extracted SCSS/JS through our existing build; do not resurrect Assetic.
5. Isolate the ExtJS surface — mount the admin UI behind a route prefix and its own layout so it does not contaminate our frontend conventions.

Compatibility. Assume PHP 8.x incompatibility until proven otherwise. Run PHPStan/lint on any PHP we intend to keep; expect to discard most of it. Asset-level reuse (SCSS, JS, templates) is version-tolerant by comparison.

Sequencing — with explicit gates.

• (a) Timeboxed spike — half a day to clone, inspect, and confirm what is actually reusable. Hard stop at the timebox.
• (b) Licensing check in parallel — a "no" from legal kills the effort regardless of technical merit. Do not spend engineering time before this gate clears.
• (c) Asset extraction and build-pipeline integration (only if (b) passes and the ExtJS runtime is genuinely required).
• (d) Layout/route wiring.
• (e) Explicit decision gate — carry the ExtJS runtime forward vs. rebuild the admin surface on a maintained UI stack (Inertia/Vue, Livewire, Filament, Nova, or a bespoke design system). Default recommendation: rebuild.

Tech-radar entry (governance artifact). Record this as a canonical "Hold — do not adopt" precedent: maintained releases, dependents, and a supported-framework match are required before we add a dependency. This entry earns its keep even if we never touch the code.

Operational Impact

Maintenance. Effectively zero upstream, and the read-only split means we cannot even upstream a patch. Budget it as permanently forked, internally owned code — or, preferably, as a one-time asset harvest with no ongoing dependency. Either way, the run-rate cost lands on us.

Support. No maintainers, no issue tracker on this repo, no security advisories. Internal support depends entirely on whether anyone has ExtJS depth; if not, the first production incident in the admin UI is an unbounded research task. That is a staffing risk, not just a technical one.

Scaling. The PHP side is negligible — container glue and asset publishing, not a runtime hot path. The real scaling question is frontend: an ExtJS 4/5 admin ships a large single-page bundle, has heavyweight client-side rendering, and does not benefit from modern code-splitting or SSR. That is a UX and performance ceiling, not a throughput problem, but it is a ceiling we would inherit.

Failure modes (risk register).

• Dependency resolution failure — Composer cannot satisfy 2016 constraints; --ignore-platform-reqs defers the failure to runtime.
• Silent runtime breakage — deprecated PHP/Symfony APIs fail only on code paths the theme touches, so it may look healthy until a specific admin screen loads.
• Asset publish drift — public assets copied out of sync with the monorepo source of truth.
• Licensing challenge — ExtJS redistribution questioned during procurement or acquisition diligence. Legal, not engineering.
• Orphaned admin surface — the theme becomes a locked-off corner of the app no one can safely modify, accumulating workarounds and knowledge debt.

Ramp-up. Moderate for asset extraction (hours to days); steep for anyone modifying ExtJS internals (weeks, and only with prior ExtJS experience). The PHP glue requires almost no ramp-up because the correct move is not to adopt it. Recommend framing the effort to stakeholders as "salvage the theme, reject the bundle," with the Sencha licensing gate before any engineering time is committed.

Roadmap items this assessment moves forward:

• Back-office/admin theming strategy. Confirms "adopt Modera" is a dead end; the roadmap should point at a maintained UI layer (Inertia/Vue, Livewire, Filament, Nova, or a bespoke design system).
• Build vs. buy vs. reuse. Reuse is off the table on evidence. Decision defaults to build or buy a maintained product.
• Vendor & partnership diligence. If Modera is proposed as a partner, this repo is a data point on their OSS maintenance posture — a read-only 2016 artifact. Frame the conversation around their current commercial offering, not archived bundles.
• Legacy-estate exit planning. For any inherited system on Modera MJR + ExtJS, this becomes a triage artifact: identifies the theming layer as a coupling point to unwind, and informs the cost model for migrating off ExtJS.
• "Custom branding" feature requests. Converts a vague ask into a concrete requirement — tokenized theming in our own UI layer — rather than a dependency hunt.

Bottom line for stakeholders: an unsupported dependency in an administrative surface, an ExtJS commercial licensing and skills obligation, and a theming layer we would have to fork and own outright within months. That is a build cost disguised as a buy. No integration work, no spike beyond the timebox, no evaluation license. Log it as Hold/Avoid with the reasoning above.