Bootstrap Bundle Laravel Package

Getting Started

This release is an asset refresh: it ships the Bootstrap 3.2.0 front-end (CSS, JS, Glyphicons fonts) and the matching Laravel glue (service provider, facade/helper, publishable Blade views). Nothing about the integration surface changed, so treat 3.2.0 as a drop-in that you re-publish and re-test — not a migration.

Minimal path from zero:

1. composer require your-vendor/laravel-bootstrap:^3.2 (placeholders — substitute the real vendor/package name from composer.json).
2. Register the provider. On Laravel 5.5+ check for auto-discovery first (php artisan vendor:publish will already list the provider's tags); otherwise add it to config/app.php providers and, if you want the helper, the aliases array.
3. Publish assets and config in one go:

   php artisan vendor:publish --provider="Vendor\Bootstrap\BootstrapServiceProvider" --tag=assets
   php artisan vendor:publish --provider="Vendor\Bootstrap\BootstrapServiceProvider" --tag=config
   

4. Reference the published files in your layout (or rely on the helper, which emits the tags for you).
5. First real use case: swap Laravel's default pagination markup for the package's Bootstrap 3 view, which is the single highest-value thing this package does and the fastest way to confirm everything is wired up.

Where to look first, in this order: the published config/bootstrap.php (CDN toggle, asset path, version string), public/vendor/bootstrap/ (did the CSS actually land?), then resources/views/vendor/bootstrap/ (the overridable views, notably pagination). The facade/helper class is thin — read it once, it's a handful of methods.

Implementation Patterns

Layout partials. Include the style/script partials rather than hardcoding <link> tags, so the CDN toggle and cache-busting version stay in one place:

{{-- resources/views/layouts/app.blade.php --}}
<head>
    @include('vendor.bootstrap.styles')
</head>
<body>
    @yield('content')
    @include('vendor.bootstrap.scripts')
</body>

Global pagination default. Set it once in a service provider instead of passing a view name to every links() call — this is where drift creeps in on larger apps:

// AppServiceProvider::boot()
Paginator::defaultView('vendor.pagination.bootstrap-3');
Paginator::defaultSimpleView('vendor.pagination.bootstrap-3-simple');

Form macros. Bootstrap 3 form markup is verbose; register macros in a dedicated FormServiceProvider and keep the error-state class logic in one place:

Form::macro('bsText', function ($name, $label = null, $value = null, $attrs = []) {
    $errors = $errors ?? session('errors');
    $attrs['class'] = trim(($attrs['class'] ?? '').' form-control'.($errors && $errors->has($name) ? ' is-invalid' : ''));
    // ... render .form-group wrapper + label + control + help-block
});

CDN vs. published assets. Pick one per environment. A common split: CDN in local dev, published files in production (no third-party dependency at runtime, no CSP surprises). Drive it from config with an env override so it's not a code change between environments.

Pipeline integration. If you compile your own Sass via bootstrap-sass, use this package for the JavaScript (and the Bootstrap-3-specific Blade views) and let your build own the CSS — otherwise you get duplicate rules and confusing specificity fights. If you don't have a build step, take both from the package and stop there.

Deployment. Because publishing skips existing files by default, add a forced publish to your deploy script before config:cache and view:cache:

php artisan vendor:publish --provider="..." --tag=assets --force
php artisan view:clear

Testing. Force the CDN off in phpunit.xml (BOOTSTRAP_CDN=false) so assertions against local public/vendor/... paths are deterministic, and add one smoke test asserting the layout contains the expected stylesheet and script tags.

Gotchas and Tips

Stale assets after the bump — the #1 issue. vendor:publish will not overwrite your existing 3.0/3.1 files. You upgrade the package, run publish, see nothing change, and assume the release is broken. Use --force, then verify by checking the version comment at the top of public/vendor/bootstrap/css/bootstrap.min.css, and hard-refresh (or confirm your cache-busting query string changed).

Glyphicons fonts are a relative path. The CSS references ../fonts/ — if you copy the stylesheet somewhere without the fonts/ directory, every icon silently disappears. When serving from a CDN, you also need Access-Control-Allow-Origin on the font files or Firefox/IE block them.

3.2.0 semantic changes worth re-testing. Bootstrap 3.2 introduced .img-responsive and .embed-responsive (use these instead of hand-rolled max-width: 100% and iframe wrappers), replaced the old .visible-*/.hidden-* responsive utilities with .visible-*-block/.visible-*-inline and .hidden-* variants (the old classes remain but are deprecated — audit any custom utility usage), and dropped IE7 support while still requiring Respond.js for IE8. Grid gutter math and .navbar/.panel spacing received fixes, so re-check modals, navbar collapse and form layouts after the swap.

jQuery version. Bootstrap 3's JS requires jQuery 1.x/2.x. If your app has moved to jQuery 3, dropdowns, tooltips and collapse break — usually silently, with only $(...).tooltip is not a function in the console. Pin jQuery per-page or stay on 2.x.

Config caching order. Publish assets and set env vars before php artisan config:cache; a cached config referencing a stale asset path or CDN flag is a confusing failure mode. If anything looks wrong, php artisan config:clear first.

Per-view links() calls. Passing a view name ad hoc to some calls and relying on the default in others produces inconsistent markup between sections that are hard to spot. Own the default centrally, and remember simplePaginate() routes to the simple view.

Extension points. Override anything under resources/views/vendor/bootstrap/... by creating the same path in your app — those win over the package's copies. For behaviour, extend the facade-backed helper class and register macros rather than editing published files, so the next --force doesn't erase your work. And keep the package version constrained (^3.2) so a future asset bump doesn't land unattended in production.