Blade Ui Kit Bootstrap Laravel Package

Getting Started

• composer require forxer/blade-ui-kit-bootstrap — the service provider is auto-discovered; there is nothing to register in config/app.php or a provider.
• Confirm the component prefix before writing markup. Components are namespaced (<x-bootstrap::alert /> style); if the prefix has been changed in the published config, follow that instead. A quick grep of the README or a throwaway Blade file is faster than guessing.
• Bring your own CSS and JS. The package renders Bootstrap 5 markup; it does not ship a stylesheet. Add bootstrap and @popperjs/core through Vite (or a CDN link for a spike) or every component will render unstyled and dropdowns/tooltips/modals will not open.
• Check composer.json constraints against your app before installing on an older Laravel — pin the major that matches your framework version rather than floating.
• First use case: replace one hand-rolled form group.

<x-bootstrap::form.input name="email" type="email" label="Email address" />

That single line gives you old('email') repopulation, the is-invalid class, and the @error message wired to the validation bag. Deleting repetitive error/old-input boilerplate is the fastest way to judge whether the package earns its place.

• Where to look first, in order: the component list in the README, then config/blade-ui-kit-bootstrap.php (prefix and per-component toggles), then the published views if you need to change markup, then the shipped Boost guideline if you use an AI agent in the repo.

Implementation Patterns

Forms as the primary surface. The form components are where the package pays for itself. Keep using plain Laravel validation ($request->validate() or a FormRequest) and let the components read the shared error bag — do not build a parallel validation layer.

<x-bootstrap::form.input name="title" :value="$post->title" />
<x-bootstrap::form.select name="status" :options="$statuses" :selected="$post->status" />
<x-bootstrap::form.textarea name="body" rows="6">{{ $post->body }}</x-bootstrap::form.textarea>

Pass :value/:selected explicitly on edit screens rather than relying on a model binding convention the package may not share.

Livewire binding. Add wire:model alongside name and keep name in sync with the Livewire property path — validation and error display key off it.

<x-bootstrap::form.input name="form.email" wire:model.blur="form.email" />

Composition with slots. Cards, modals, and alerts are slot-based; use named slots where offered instead of injecting raw HTML into the default slot.

<x-bootstrap::modal id="confirm-delete" title="Delete post?">
    This cannot be undone.
    <x-slot:footer>
        <x-bootstrap::button variant="secondary" data-bs-dismiss="modal">Cancel</x-bootstrap::button>
        <x-bootstrap::button variant="danger" wire:click="delete">Delete</x-bootstrap::button>
    </x-slot:footer>
</x-bootstrap::modal>

Standardize with thin wrappers. If your design system needs default sizes, required markers, or a house input-group layout, create resources/views/components/form/input.blade.php that forwards attributes to the package component. One wrapper absorbs every future markup change and keeps call sites short.

Choose one override strategy. Either publish views and edit them, or leave the package views untouched and wrap. Mixing both means an upgrade will silently revert half your customizations.

Laravel Boost / AI guidelines. If the repo uses Laravel Boost, php artisan boost:install picks up the package's guideline file so agents emit correct component markup. This is the cheapest way to stop an AI assistant from inventing <x-input> names that do not exist.

Gotchas and Tips

• Guideline files are Blade, not Markdown. The 3.2.1 fix is worth internalizing: the shipped guideline wrote {{ }} literally, Blade compiled it as an echo, and rendering exploded with Too few arguments to function e(). If you edit or add a guideline (or any published .blade.php that documents Blade syntax), escape literal braces as @{{ }} and @{% … %}. Symptom to recognize: an install or render failure citing e() rather than your template.
• Publish-then-upgrade is the main maintenance risk. Once views are published, they are pinned at that version. After each package upgrade, re-publish into a temp directory and diff — do not blindly overwrite, and do not blindly skip, or you inherit fixed bugs.
• Dropdowns, modals, and tooltips need the Bootstrap JS bundle and Popper. A component that renders correct markup but does not open is almost always a missing script, not a package bug.
• Nested field names. For array inputs use dot notation consistently (items.0.name) so old() and the error bag resolve; a mismatch renders the component with no error state and looks like a component failure.
• Livewire + Bootstrap modal state. Bootstrap manages modal visibility outside Livewire's DOM diffing. Reach for wire:ignore.self on the modal root and drive open/close from Livewire events, otherwise the backdrop gets stuck.
• Attribute pass-through. data-bs-* attributes and wire:* directives pass through cleanly; avoid colon-prefixed Alpine attributes on components that already bind their own attributes, since they can be swallowed by the component's attribute bag.
• Debugging order: php artisan view:clear first (compiled component views go stale surprisingly often), then render the component in a bare Blade file with no layout to isolate whether the problem is markup or your CSS/JS pipeline.
• Extension points, in increasing cost: config (prefix, component toggles) → wrapper components → published views → your own component class extending the package's. Stay as far left as your requirements allow.
• Version pinning. This is a patch release with no API change, so a ^3.2 constraint is safe and will pull the fix. Keep the constraint at the minor level and read the changelog on minor bumps — markup-only changes in view files still affect anyone who published them.