Mjr Box Select Bundle Laravel Package

Technical Evaluation

Architecture fit — the headline finding is a platform mismatch. Despite the framing of this evaluation, melk/mjr-box-select-bundle is not a Laravel package. The -bundle suffix, the MJR namespace, and the ExtJS asset reference point to a Symfony bundle for MJR (dmelk's Symfony-based CMS). Laravel has no bundle concept: there is no ServiceProvider, no config/*.php publish hook, no Facade, and no Laravel-targeted autoloading here. What little Laravel-relevant value exists is the vendored Ext.ux.form.field.BoxSelect front-end widget, not the PHP wrapper. Any Laravel adoption is therefore a re-homing exercise, not an integration.

Integration feasibility — low. Two viable paths, both requiring net-new work:

1. Port the wrapper: fork the bundle, replace the Symfony bundle class with a Laravel ServiceProvider that publishes the JS asset, and register the field definition. Tractable but non-trivial, and you inherit the widget's ExtJS dependency.
2. Bypass the package entirely: vendor the .js UX component directly into resources/js and wire it through Vite/Mix. This is almost certainly the correct call — the PHP layer contributes nothing to a Laravel app.

Either path inherits the real constraint: ExtJS is Sencha-licensed (GPLv3 or commercial). That is a licensing decision that gates the technical one, and it must be resolved before any spike proceeds.

Technical risk — high, and concentrated off-PHP. The package shows 0 stars, 0 dependents, no release cadence, and no visible CI or test suite. It targets an ExtJS-era widget (roughly ExtJS 4/5 vintage) with no version pinning guidance. The supply-chain profile is "abandoned single-author utility," which is tolerable for a decorative widget and not tolerable for anything load-bearing.

Key questions for the requester:

• Is the target admin UI ExtJS-based at all, or is this request based on the package name rather than its contents?
• Do we hold a commercial Sencha license, or are we subject to GPLv3 obligations?
• Is the requirement BoxSelect specifically, or the tag/multi-select UI pattern? The latter has a dozen maintained modern equivalents.
• Who owns the fork if we adopt it, and for how long?

Integration Approach

Stack fit — poor at the front end. A Laravel app today is typically Blade/Livewire/Inertia plus Vite, with Alpine or Vue owning DOM reactivity. ExtJS is a full RIA framework with its own class system, component lifecycle, and DOM ownership. An ExtJS field can be isolated inside a Blade page and made to work, but it will not compose with Livewire round-trips, Alpine reactivity, or Tailwind-driven layout. Treat it as an iframe-grade boundary, not a native component.

Migration path — recommend replacing, not porting. For the tag/multi-select pattern, Tom Select, Select2, or Choices.js deliver equivalent UX in ~10 lines of Laravel code with no license encumbrance and no ExtJS runtime. If ExtJS is already the house standard for the admin surface, then port the wrapper (path 1 above) and accept the cost; if it is not, the package has no reason to enter the dependency graph.

Compatibility — expect resolution conflict. The bundle's Symfony constraints are almost certainly pinned to Symfony 2.x/3.x-era versions. Composer resolution will likely fail outright against modern Symfony, and against Laravel it is meaningless regardless. PHP 8 compatibility of the original is unverified; the JS is the only part with a plausible compatibility story, and even that assumes a matching ExtJS major version.

Sequencing (if pursued):

1. Confirm the admin UI's actual front-end stack — this may terminate the evaluation.
2. Resolve the Sencha license question in writing.
3. Spike: vendor the UX JS into a scratch branch, load it against the exact ExtJS version in use.
4. Only then build a thin Laravel asset-registration wrapper (asset only — skip the PHP bundle).
5. Accessibility and keyboard QA, then document the fork.

Operational Impact

Maintenance — you inherit it whole. No maintainer, no releases, no CI, no test coverage. Any adoption means creating a fork with a named owner, a pinned commit, and an internal changelog. Absent that, assume it decays silently.

Support — none. No vendor, no community, and no documentation beyond the repository README. Incident debugging falls entirely to whichever engineer learned ExtJS internals that week.

Scaling — client-side only, with a heavy floor. The widget's runtime cost is trivial for small option sets; the framework cost is not. Loading ExtJS into a Blade page adds hundreds of KB of parse-and-execute budget, a second CSS reset that will fight Tailwind, and global namespace pressure. It also complicates the Vite build and code-splitting story. Server-side scaling impact is nil.

Failure modes to watch:

• Composer dependency resolution failure on require (most likely first failure).
• Sencha license audit surfacing after deployment.
• ExtJS major-version drift breaking the widget on framework upgrade.
• Asset pipeline breakage as Vite config evolves around an unmanaged global script.
• Accessibility gaps typical of that widget generation — verify keyboard and screen-reader behavior before shipping to internal admin users.
• No upstream security patching for the JS blob.

Ramp-up — high cost, low return. ExtJS competency is scarce in the current Laravel hiring pool. If the team is oriented around Blade/Tailwind/Livewire, the learning investment is disproportionate to the payoff of a single multi-select field. Budget for one engineer to spend a week on the spike before committing to the fork; the honest expected outcome of that spike is a recommendation to use Tom Select.