Ux Bootbox Laravel Package

Getting Started

This is a Symfony UX bundle, not a Laravel package. Before writing any code, confirm that reality with composer show krystal-sf/ux-bootbox — you'll see symfony/ux-* in the requirements and no extra.laravel.providers. Laravel's package auto-discovery will find nothing to register, so the "install" step below is only useful if you're mining the source.

The honest day-to-day answer for a Laravel dev: don't composer require this. Open the GitLab repo, read three files, and rebuild the ~40 lines of glue yourself against your own stack. The whole package is a Stimulus controller wrapping Bootbox.

What to read first (10 minutes, in order):

1. composer.json — tells you the real dependency chain: which bootbox version, whether jquery is a hard require (Bootbox ≤5 does, 6.x doesn't), and whether a Flex recipe exists. This decides feasibility more than the package itself.
2. assets/controllers.json — the Stimulus identifier you'd use in Twig (data-controller="..."). In Laravel this maps to Alpine or a small vanilla module instead.
3. assets/controllers/*.js — one or two short files that are the documentation. They call bootbox.alert/confirm/prompt and marshal options. Copy the option shape; that's the value.

Your first use case in Laravel is almost certainly destructive-action confirmation on a delete form — the one place a modal.confirm pays for itself immediately:

{{-- resources/views/components/confirm-delete.blade.php --}}
<form method="POST" action="{{ $action }}"
      x-data @submit.prevent="
        bootbox.confirm(@js($message ?? 'Delete this?'), ok => {
          if (ok) $el.submit()
        })">
    @csrf @method('DELETE')
    <button type="submit" class="btn btn-danger">{{ $label ?? 'Delete' }}</button>
</form>

Wire bootbox via Vite (npm i bootbox bootstrap), expose it on window, and you have everything this package provides — without the Symfony surface. If you do have a Symfony + Bootstrap app, composer require krystal-sf/ux-bootbox, bin/console assets:install, and use the registered Twig/Stimulus helpers directly.

Implementation Patterns

The "wrapper, don't scatter" pattern. Expose exactly one interface — a Blade component or an Alpine directive — so a future replacement (Radix-style headless, Alpine x-modal, Livewire) is a single-file change. Do not sprinkle bootbox.confirm() calls across ten views; centralize:

// resources/js/dialogs.js — one public API
import bootbox from 'bootbox';

export const confirm = (message, opts = {}) => new Promise(resolve =>
  bootbox.confirm({ message, ...opts, callback: resolve }));
export const alert   = (message, opts = {}) => bootbox.alert({ message, ...opts });
export const prompt  = (message, cb, opts = {}) => bootbox.prompt({ message, ...opts, callback: cb });

Programmatic invocation from server-rendered markup. This is the pattern the package is built around and it translates directly: a Blade/Alpine x-data binds a click to a dialog whose text comes from a data-* attribute or a translated @js() string. Keep the message server-side (i18n, entity names) and the behavior client-side.

Promise-based confirm → form submit. The one genuinely useful pattern: intercept submit, open a confirm dialog, and on true submit programmatically (not the original event), so you avoid double-fire. Bootbox's callback form is what the package's Stimulus controller marshals.

Integration tips:

• CSRF/auth stays on the server. A JS confirm is a UX affordance, not a security control — the DELETE route must still authorize. Don't let the dialog lull you into skipping $this->authorize().
• Bootstrap-only. If you're on Tailwind, use Alpine's x-modal or a headless component. Bootbox markup assumes Bootstrap 4/5 classes; you'll fight it otherwise.
• Asset-mapping equivalence: Symfony AssetMapper ≈ your Vite entry. import 'bootbox' in resources/js/app.js and you're at parity with the bundle's asset step.

Migration mindset. If the goal is "adopt the idea, not the dependency": port the option-object shapes (title, message, buttons, callback) into your own component so feature parity is a checklist, then delete the fork.

Gotchas and Tips

• Silent no-op install. composer require will succeed even if the repo is private/unlisted with a VCS entry, and Laravel will happily load the class files without ever registering anything — no error, no dialogs. The most common first failure, easily misdiagnosed as a config bug.
• Symfony extension points are inert in Laravel. DI Extension, config/bundles.php, Flex recipes, Twig namespace registration — none of it runs. You port Twig → Blade by hand.
• jQuery trap. Pin the Bootbox version deliberately. Bootbox 4/5 drags in jQuery; if your app is jQuery-free you want Bootbox 6 (or a native <dialog>). Check composer.json/npm ls jquery before committing.
• Double-init / modal stacking. Two Bootstrap JS bundles (or Bootbox + your own modal manager) produce unreachable backdrops and stuck scroll locks. Audit that bootstrap is loaded once.
• Twig runtime leakage. Any code path assuming Twig throws under Blade. This is why "just require it" doesn't work — the helpers have no Laravel equivalent.
• Styling collision. Bootbox assumes Bootstrap DOM; in a Tailwind layout expect visual regressions. Not worth reconciling — pick one modal implementation.
• No a11y guarantees. Bootbox's focus-trap and aria-modal posture is dated. If accessibility is a requirement, build on a maintained headless primitive instead.
• Supply-chain posture. Zero stars, zero dependents, single-maintainer, company-namespaced GitLab. Treat it as "vendoring code," not "depending on a library": fork to your namespace, strip Symfony/Twig, pin to a commit SHA, and own the upgrade path.
• Extension point if you must reuse it: the only salvageable, stack-neutral artifact is the Stimulus controller's option-object contract and the JS asset. Everything else is Symfony-specific and should be discarded in a Laravel port.