Ux Bootbox Laravel Package

Product Decisions This Supports

• Framework scoping — the first product decision. The package is described as "Bootbox Modals for Krystal Symfony Projects." Despite the "Laravel/PHP" framing in the brief, every integration surface it ships (Symfony Flex, DI extension, Twig namespace, Stimulus controllers.json) is Symfony-specific. A PM should treat the framework question as a gate, not a detail: on Laravel the package is effectively inert, and the only useful artefact is its pattern. Confirm the target stack before scope, budget, or roadmap commitments are made.
• Build vs. buy on commodity UI. Confirmation prompts, destructive-action alerts, and "form in a modal" flows are commodity UI that every product needs and no customer will ever pay for. The real decision is not "buy this package" — it is "adopt a wrapper" vs. "write ~40 lines of our own controller." At zero stars, zero dependents, and no maintenance signal, the honest frame is vendoring code, not depending on a library.
• Design-system consolidation. If your product runs Bootstrap, this is Bootstrap-native by construction. If you run Tailwind, Bulma, or a custom design system, adopting it introduces a second modal implementation, a second set of accessibility behaviours, and a second CSS burden — a decision against consolidation, not for it. This is a design-system strategy call, not an engineering call.
• Destructive-action safety. A consistent, low-ceremony confirmation UX reduces accidental data loss on delete/disable/irreversible-step flows. Even if you never ship this package, its shape is a reasonable target spec for whatever you do ship, and the safety outcome is measurable in support tickets and incident logs.
• Reference spec for a first-party component. Useful as a design brief: what should our modal abstraction expose? Title/body/buttons, alert vs. confirm vs. custom, promise-based callbacks, programmatic invocation from server-rendered markup. Use it to bound the ticket for your own component rather than as a shipped dependency.
• Risk register entry. Single-maintainer, company-namespaced GitLab repo, zero public dependents, no disclosed security process. That is a standing liability on a product surface (modals are user-facing, sometimes handle destructive actions) — worth logging explicitly so future roadmap reviews can cite it rather than re-litigating adoption.

When to Consider This Package

Consider it only if all of the following are true:

• You are on Symfony, already using the Krystal UX package family, with conventions and version pinning set by that stack.
• You are committed to Bootstrap, and either already ship Bootbox.js or are willing to adopt it as the modal runtime.
• You need modal/confirm parity with an existing Krystal front-end, and the alternative is re-deriving their markup and callback conventions by hand.
• Your team is small enough that a ~40-line wrapper is genuinely not worth writing, and you are comfortable forking or vendoring if upstream goes quiet.
• Your modal needs stay inside alert / confirm / simple custom territory — no nested modals, no async form validation, no unsaved-changes guards.

Look elsewhere — or build in-house — when:

• You are on Laravel. This is out of scope. There is no integration path, only a reimplementation. Use Livewire/Alpine or a Blade component against your own design system instead.
• You are on Tailwind, Bulma, or a custom design system. Bootbox's Bootstrap dependency is a hard conflict, not a styling preference.
• You need accessibility guarantees — focus trapping, aria-modal, screen-reader announcements, keyboard containment. Bootbox's a11y posture is dated; a maintained headless library or your own component is the safer choice.
• You need tests, documentation, or a security response process. A 0-star, 0-dependent package evidences none of these.
• Your modal needs have outgrown confirm/alert — nested modals, async validation, optimistic concurrency, unsaved-changes guards. That is a component, not a wrapper.
• Your UI decisions sit under a design-system roadmap. Adding a modal manager outside your system fragments the layer you are actively trying to consolidate.

How to Pitch It (Stakeholders)

To executives: This is a small glue package that lets Symfony applications open Bootstrap-styled confirmation dialogs without hand-rolling markup. It is not a platform bet, it has no community, no dependents, and no maintenance signal, and — importantly for us — it is built for Symfony, not Laravel, so it does not plug into our stack at all. My recommendation is to treat it as a reference implementation: we copy the design pattern into a first-party component, not the dependency. Cost is measured in hours, and it removes a long-term ownership and security risk entirely. There is nothing here a customer would ever pay for, which is exactly why the right move is to own our own version of it.

To engineering: The package is a thin Symfony UX/Stimulus wrapper around Bootbox.js. Its abstraction is shaped correctly — promise-based confirm callbacks, alert/confirm/custom variants, programmatic invocation from server-rendered pages — and that shape is the asset, not the code. If we were on Symfony + Bootstrap, porting the contract into our own Stimulus controller is roughly a half-day and gets us first-party control over accessibility and theming. We are on Laravel, so the practical takeaway is: build the equivalent as a Blade component (or Livewire action pattern) against our own design system, backed by a small Vite entry that imports bootbox from npm if we want it at all. Do not add krystal-sf/ux-bootbox to composer.json — the install "succeeds" and does nothing, which is the worst possible failure mode for onboarding. Recommend: do not adopt; mine for design; close the evaluation. Revisit only if we standardize on the Krystal Symfony stack.