Laravel Bootstrap Components Laravel Package

Getting Started

Before installing, check the constraints. This package was last released in September 2021 and is archived. Read composer.json on the repo first and compare its illuminate/* and php constraints against your app's Laravel version. On Laravel 10/11 you will likely get a dependency conflict; that is a deliberate signal, not an obstacle to route around with --ignore-platform-reqs.

Install and publish.

composer require okipa/laravel-bootstrap-components
php artisan vendor:publish --provider="Okipa\LaravelBootstrapComponents\LaravelBootstrapComponentsServiceProvider"

Publishing usually exposes a config file and a resources/views tree. Publish to a path you control and commit it — you will be maintaining those views yourself.

Where to look first, in this order:

1. README.md — the authoritative list of component names and their props. Everything else is guesswork without it.
2. src/ — find where components are registered (Blade::component, Blade::componentNamespace, or loadViewsFrom). That tells you the exact tag syntax (<x-input> vs <x-bootstrap-input> vs @component('bootstrap-components::input')).
3. resources/views/ — this is the actual product. Skim one input, one select, one checkbox to see how they consume $errors, old(), and $name.
4. config/ — defaults for classes, wrappers, and locale/error display.

Ensure Bootstrap is actually loaded. These components emit Bootstrap markup (form-group, form-control, invalid-feedback, is-invalid) but ship no CSS or JS. Add Bootstrap 4 or 5 to your layout first, or you'll debug "broken" components that are rendering correctly into an unstyled page.

First use case: a single create form with server-side validation. Put a text input and a submit button on a page, submit something invalid, and confirm the field re-populates via old() and shows the error message. That one loop exercises the majority of the package's value. If it doesn't work out of the box, stop there — it won't get better deeper in.

Implementation Patterns

Treat it as a validation-aware input layer, not a form builder. The package's real job is: given a field name, render label + control + old value + error message + Bootstrap error classes. Lean on that and stop.

Per-resource form partials. Keep forms in resources/views/admin/posts/_form.blade.php shared between create and edit, with the model passed in. Because the components read old($name, $value) semantics, the same partial serves both actions if you pass the model's current values as defaults.

Pair with FormRequest, always. The components assume $errors is populated by Laravel's validation pipeline. Validating inline in the controller with $request->validate() works, but a FormRequest keeps the rules next to the field list and makes the "field name in rules == field name in Blade" contract easy to audit.

// PostRequest
'published_at' => ['nullable', 'date'],

<x-input name="published_at" type="datetime-local" :value="old('published_at', $post->published_at)" />

Wrap, don't scatter. Define your own thin components (<x-field.text>, <x-field.select>) that delegate to the package's. When the package inevitably stops working on a future Laravel, or you swap Bootstrap versions, you rewrite a dozen wrapper files instead of grepping 200 views. This is the single highest-leverage pattern with an archived dependency.

Named error bags are the exception to watch. If you use multiple forms on one page, $request->validateWithBag('createPost', ...), or Laravel Breeze-style updatePassword bags, verify the components accept an error-bag argument. If they don't, don't fight it — use the package for the simple forms and hand-write the complex one.

Livewire and Inertia don't compose with this. Livewire re-renders and manages its own error bag and dirty state; old()-driven Blade components will show stale values on the second render. Inertia doesn't render Blade for form submissions at all. If either is in your stack, this package covers a shrinking slice of your app.

Selects and checkboxes deserve their own read. Options arrays, selected-state resolution, and old() on checkbox groups (where old() returns an array or null, not a scalar) are where these packages most often have sharp edges. Test each once, manually, before you ship them.

Gotchas and Tips

No upstream support. 19 stars, archived since 2021. There is no one to ask; if a Laravel upgrade breaks it, you fix it. Fork it into your org and use a VCS repositories entry, or vendor the views into your own resources/views/components. Budget a day to decouple before you depend on it widely.

Bootstrap 4 vs 5 drift. BS5 dropped form-group/custom-select, changed invalid-feedback display from sibling to parent-driven, and reworked spacing utilities. The published views are BS4-era. Expect to edit wrappers and validation markup if you're on BS5 — or pin BS4.

Publishing views creates silent drift. Once published, package updates (there won't be any, but if you fork) no longer reach your app. Publish deliberately, commit the diff, and document that vendor/okipa/.../resources/views is no longer the source of truth.

Component name collisions. If the package registers <x-input> and you later add your own App\View\Components\Input, the app-level component wins and the failure is confusing. Run php artisan view:clear after changes and check php artisan about / your service provider for registration order.

Errors only render if the middleware is present. $errors comes from ShareErrorsFromSession. In API-only routes, exception-handler-rendered responses, or tests that don't follow a redirect, $errors is empty and inputs render clean — which looks like the component is ignoring validation. It isn't.

File inputs are always a special case. old() cannot repopulate a file input, and the package can't help. Handle hasFile() explicitly and show the existing filename on edit.

Debugging moves fast if you narrow the layer. Isolate in three steps: (1) render the component in a bare Blade view with no layout to rule out CSS/layout masking; (2) dd($errors->get('field')) inside the view to confirm the bag has the key; (3) php artisan view:clear && php artisan optimize:clear, since cached compiled views are the most common "my edit did nothing" cause.

Extension points worth knowing: the service provider's registerComponents/loadViewsFrom calls for aliasing, the config file for global class defaults, and class extension if components are class-based — you can subclass and re-register under the same alias to override behavior without touching vendor files.

Verdict for day-to-day use: reasonable in 2021 for a Bootstrap 4 admin panel on Laravel 8; today it's a small amount of convenience against an unmaintained dependency and a Bootstrap-version migration risk. If you're on Laravel 8/9 with BS4 and a handful of forms, the wrappers-in-your-own-app pattern makes it palatable. On Laravel 10+, use plain Blade + @error + a hand-rolled field component; you'll write maybe 80 lines and own all of it.