- Is digineers/bootstrap-bundle a Laravel package?
- No. The supplied Composer name digineers/bootstrap-bundle does not match the documented artifact, which is BraincraftedBootstrapBundle, a Symfony 2/3 bundle. It registers through AppKernel and depends on Twig, Assetic, Bootstrap 3, and jQuery, so it is not installable or usable as a Laravel package. For Laravel, treat this as out of scope.
- Can I install braincrafted/bootstrap-bundle in Laravel 10, 11, or 12?
- No, not as a supported integration. The bundle targets Symfony 2.3 through 3.0 and PHP 5.x-era code, with Composer constraints that conflict with modern Laravel and PHP 8.3/8.4. Laravel also lacks the Symfony bundle/kernel extension model it relies on. You would need to reimplement the styling and form behavior natively.
- Why does the repository link point to FOSJsRoutingBundle instead of bootstrap-bundle?
- That mismatch is a provenance red flag in the supplied metadata. The repository URL points to shinyvision/FOSJsRoutingBundle, a different Symfony bundle that exposes server routes to client-side JavaScript, while the README describes BraincraftedBootstrapBundle and the vendor name digineers matches neither. Until the actual artifact is confirmed, you cannot trust what Composer would install. Verify the source repository and Packagist entry before any evaluation.
- What Laravel versions does this package support?
- None. It is a Symfony bundle, not a Laravel package, so there is no Laravel service provider, configuration file, or Blade integration. The documented compatibility is Symfony 2.3 to 3.0 with Bootstrap 3 and jQuery 1.10/1.11. It should not be considered for any Laravel version.
- How do I install BraincraftedBootstrapBundle?
- For a legacy Symfony 2/3 app, require braincrafted/bootstrap-bundle via Composer, register BraincraftedBootstrapBundle in AppKernel.php, add Bootstrap and jQuery as dependencies, and configure Assetic to compile the LESS files. The README recommends dev-master or explicit versions such as 2.1.*. This installation path does not apply to Laravel.
- What is the Laravel equivalent of BraincraftedBootstrapBundle?
- There is no direct equivalent because the bundle is Symfony-specific. In Laravel, install Bootstrap 5 from npm and compile assets with Vite, build Blade components for form controls and validation errors, and use session flash partials for alerts. If the real requirement is exposing routes to JavaScript, use Ziggy rather than FOSJsRoutingBundle.
- Is BraincraftedBootstrapBundle abandoned or still maintained?
- It is effectively abandoned. The last release, v2.2.0, was in January 2016, and the stack it targets, including Symfony 2.3–3.0, Bootstrap 3, jQuery 1.10/1.11, and Assetic, is end of life. There is no active security release channel, so any vulnerability in the dependency tree becomes your responsibility. Adopting it for new work is not recommended.
- Does this bundle support Bootstrap 5 or only Bootstrap 3?
- The documented integration is for Bootstrap 3, with optional support for the official Sass port and Font Awesome. There is no indication of Bootstrap 4 or Bootstrap 5 support. Modern Laravel projects should use Bootstrap 5 directly via npm and Vite.
- How do I replace Bootstrap 3 Twig form themes with Laravel Blade?
- Recreate the form markup as Blade components rather than translating Twig themes. Build components for inputs, selects, checkboxes, buttons, and validation errors using Bootstrap 5 classes and Laravel's @error directive. Use session flash partials for alerts and install icons through npm instead of the bundle's Twig helpers. This is typically a few engineer-days for a representative form surface, not a migration project.
- What are the security and production risks of using this package?
- The risks are high: end-of-life Symfony, Bootstrap, jQuery, and Assetic components; a single-maintainer history; zero dependents; and no security release process. The repository, README, and vendor mismatch adds supply-chain uncertainty because the evaluated code may not be the installed code. In production you would own patching an unmaintained transitive dependency tree. Platform policy should reject new EOL dependencies.