- Which Laravel versions does caouecs/bootstrap3 support?
- It was built for legacy Laravel 4.x and 5.x applications, and its Composer constraints pin illuminate/support to those majors. It is a nominal fit on Laravel 4.x through 5.4, a poor fit on 5.5 through 5.8, and will not install on Laravel 6 or later. If your application runs a modern Laravel release, pull Bootstrap in through npm or Vite instead.
- How do I install caouecs/bootstrap3 with Composer?
- Run composer require caouecs/bootstrap3 from the root of your legacy Laravel project. Expect to add the service provider to config/app.php manually afterward, because the package predates package auto-discovery. Once installed, publish the assets and reference them from your Blade layout.
- Do I have to register the service provider manually in config/app.php?
- Yes. The package predates Laravel package auto-discovery, so you add its service provider to the providers array in config/app.php. That is a small but permanent piece of configuration debt. Remember to remove the entry when the package is removed or the application is upgraded.
- How do I publish the Bootstrap 3 CSS and JS files into public/?
- The package exposes Bootstrap 3 dist assets for publishing, so you typically run php artisan vendor:publish and select its tag or provider. Check the target directory before running it on a production server so you do not overwrite Bootstrap files the team copied in by hand. If your app already vendors Bootstrap 3 manually, reconcile those files first.
- Can I use caouecs/bootstrap3 on Laravel 6, 7, 8, 9, 10 or 11?
- No. Its Composer constraints pin illuminate/support to the 4/5 era, so installation fails on Laravel 6 and newer. The package is not the real blocker there, the application's framework version is, and fixing that is a modernization decision rather than a package swap. On modern Laravel, install Bootstrap with npm and build it through Vite or Mix.
- Does caouecs/bootstrap3 only publish assets, or does it also provide Blade helpers?
- Its core job is making Bootstrap 3's prebuilt CSS and JS files available to your application, which is essentially a vendor:publish wrapper. Documentation references form, HTML, and pagination helpers in places, so check vendor/caouecs/bootstrap3 before assuming it is assets only. That distinction drives removal cost, because helper-driven markup is much harder to unwind than a couple of static files.
- Is Bootstrap 3 still safe to use in a Laravel application?
- Bootstrap 3's final patch was 3.4.1 in 2019, and it carries known issues including CVE-2019-8331 plus the earlier tooltip, popover, and collapse XSS reports. It also assumes jQuery, which modern Laravel does not ship. Treat any Bootstrap 3 usage as inherited risk and plan a move to Bootstrap 5 rather than trying to patch it.
- How do I remove caouecs/bootstrap3 from an existing Laravel app?
- First determine whether Bootstrap 3 is load-bearing for a design system or merely incidental. If it is incidental, copy the Bootstrap 3 CSS and JS into resources/ or add [email protected] to package.json, update your layout references, drop the provider entry from config/app.php, and run composer remove caouecs/bootstrap3. If it is load-bearing, scope it as a separate UI migration project rather than a one-sprint cleanup.
- Is caouecs/bootstrap3 still maintained?
- It is a small, single-maintainer package with a very low install base, so do not expect active issue triage, a security disclosure channel, or a reinstall path if the repository is archived. If you need it long term, the practical answer is to fork it or vendor the static Bootstrap files into your own repository. Record that as a risk acceptance item owned by the application team rather than assuming upstream support.
- What is a good alternative to caouecs/bootstrap3 for Laravel?
- If you must stay on Bootstrap 3 for pixel parity, add [email protected] to package.json and compile it with Vite or Mix, or copy the dist files into resources/. If you can move forward, Bootstrap 5 through npm and Laravel's Vite setup is the current approach and removes the jQuery dependency. Either option avoids a Composer package that pins the application to Laravel 4/5.