Mjr Box Select Bundle Laravel Package

Product Decisions This Supports

• Form UX for legacy admin surfaces. If the product runs an MJR (Symfony-based) back office with Sencha ExtJS forms, this bundle supplies the tag/token input widget (Ext.ux.form.field.BoxSelect) for multi-value fields — categories, recipients, labels, filter chips. That is the entire scope of the decision it informs.
• Build vs. buy (leaning build). The bundle is a thin integration shim: asset registration plus a form-field wiring for Ext.ux.form.field.BoxSelect. The real logic lives upstream in the ExtJS user extension. The honest build-vs-buy framing is "vendor the UX extension and write the ~50-line glue ourselves" rather than "take a dependency."
• Roadmap triage. Any roadmap item that requires free-form tagging or multi-select-with-chips in the ExtJS admin can treat this as one implementation option, not the deciding factor. The user-facing UX (a token field) is a commodity pattern; the package choice should never gate a feature commitment.
• Maintenance-risk accounting. Zero stars, zero dependents, single maintainer (dmellk), MIT, effectively unindexed. This is a "vendor and own" decision, not an "adopt and track" decision — which is itself a useful signal for dependency-consolidation or admin-UX-replacement discussions.
• Stack-fit evaluation. Despite being catalogued in PHP ecosystems, this is a Symfony bundle for ExtJS, not a Laravel package. If the product is Laravel-first, this is a non-option and the decision collapses to "build the equivalent in our own front-end stack."

When to Consider This Package

Consider it only when all of the following hold:

• You are already on MJR/Symfony with ExtJS forms in production, and the admin asset pipeline expects Symfony bundles.
• You need a tag-style multi-select in a legacy/internal admin screen — not a customer-facing product surface.
• You are prepared to fork and own the code: pin the version, freeze the dependency, and accept that upstream will not ship fixes.

Look elsewhere — and say so plainly — when:

• Greenfield or modernising. Any React/Vue/Livewire/Alpine front end has mature tag-input components with active maintenance. Do not carry ExtJS-era glue into a new build.
• Not on MJR/ExtJS. The package provides no value outside that narrow stack; there is no Laravel integration despite the catalogue listing.
• Support, security review, or SLA is required. Zero stars and zero dependents means no community validation, no CVE-watching, no incident history to learn from. It will likely fail a dependency-approval gate.
• You need guaranteed compatibility. No release cadence, no issue traffic, no tests of note — compatibility with future Symfony/ExtJS versions is your problem, not the maintainer's.

If forced to adopt: treat it as a vendored snippet, not a Composer dependency of record. Copy the integration into the app, attribute under MIT, and remove the third-party supply-chain surface.

How to Pitch It (Stakeholders)

To executives: This is a very small, unmaintained open-source glue library that makes one legacy admin widget work. It is not a strategic dependency and should not appear in architecture or vendor-risk narratives. There is no commercial support, effectively no user base, and no maintenance signal. Recommendation: do not adopt as a dependency; if the widget is needed, we absorb roughly a day of engineering to replicate the integration in-house. Cost is negligible either way — the real decision is whether we keep investing in the ExtJS admin at all.

To engineering: It's a Symfony bundle wrapping Ext.ux.form.field.BoxSelect for MJR. MIT, single maintainer, no dependents. Treat it as reference implementation, not a dependency: read it, replicate the ~50 lines of asset and form-field wiring in our own bundle or admin module, and skip the supply-chain risk. If you must pull it in, fork it, pin it, and add it to the "owned by us, no upstream expectation" list.

PM framing / decision to record: The product requirement is "tag-style multi-value input in admin forms." The package is one low-quality implementation path for one legacy stack. Log the requirement, not the package; revisit whether the ExtJS admin is still the right surface before spending any time on bundle-level integration.