Bootstrap Bundle Laravel Package

Getting Started

This bundle is a Symfony2 bundle, not a Laravel package, so you cannot composer require it into a Laravel app and expect a service provider to appear. Treat it as a reference implementation of Bootstrap integration rather than a dependency.

Minimal steps to actually use it:

1. Skim the repo layout before anything else. Look for:
   • Resources/public/ — the Bootstrap CSS/JS images and fonts.
   • Resources/views/Form/ — Twig form theme blocks (bootstrap_3_layout.html.twig-style files) if present.
   • DependencyInjection/ — Configuration.php and the extension class, which tell you exactly what options the bundle exposes.
   • TwitterBootstrapBundle.php — confirms the Symfony bundle contract (Bundle class, getContainerExtension).
2. Decide what you actually want. For a Laravel day-to-day, that is almost always one of: (a) Bootstrap front-end assets, (b) form markup conventions, (c) Twig helpers you'll rewrite as Blade. None require the bundle itself.
3. For assets, skip the bundle and install Bootstrap properly: npm install bootstrap and import it in resources/js/app.js / resources/css/app.css through Vite.
4. First use case: port a single form theme block — e.g. the text input wrapper — into a Blade component (resources/views/components/form/input.blade.php) and render it from a Form:: macro or a plain view. That gives you 80% of the value in an afternoon.

Implementation Patterns

Asset extraction pattern. Copy Resources/public/* into public/vendor/twitter-bootstrap/ if you must self-host the exact version the bundle ships. In practice, prefer a pinned npm version so you control the Bootstrap major (the bundle era implies Bootstrap 3.x, which differs sharply from 5.x classes like form-control, mb-3, is-invalid).

Form theme → Blade component pattern. The bundle's Twig form themes wrap each widget in Bootstrap markup. Map them one-to-one:

• form_row block → <x-form.row> component.
• form_widget / input blocks → <x-form.input>, <x-form.select>, <x-form.textarea>.
• form_errors block → <x-form.errors> using @error / $errors->first().
• form_label block → <x-form.label>.

Keep the component API mirrored to Symfony's block names so the port stays mechanical and reviewable.

Configuration mapping pattern. If the bundle's Configuration.php exposes options (e.g. CSS framework version, template paths, asset config), translate them into Laravel equivalents: config/view.php paths, config/filesystems.php disks, or a small config/bootstrap.php of your own. Do not attempt to reuse Symfony DI — Laravel's service container and bundle config are not compatible.

Workflow tip. Use the bundle as a spec while migrating or comparing. Pull up its form theme file in one pane and your Blade component in the other, and diff the output HTML against the Bootstrap docs for the version you target. This is fast and avoids guesswork.

Integration pattern for existing Symfony→Laravel ports. If you're moving an app from Symfony2 to Laravel, inventory every form_theme used and the Twig extension helpers (bootstrap_* functions). Reimplement helpers as Blade directives or small PHP helpers to preserve view logic.

Gotchas and Tips

• Wrong ecosystem. There is no Laravel service provider, no facade, no publishable config. Any Bundle class, services.yml, or AppKernel registration is dead weight in Laravel — strip it.
• Bootstrap 3 legacy. Symfony2-era bundles assume Bootstrap 3 markup (col-md-*, form-group, help-block). Bootstrap 5 renamed most of these. Do not copy class names verbatim into a modern Blade component without updating them.
• Twig vs Blade syntax clash. Form themes use {{ form.vars.* }}, {% block %}, and Twig filters. These won't compile in Blade; translate block inheritance into Blade component slots and @props.
• Archived, 3 stars, 0 dependents. No security patches, no Bootstrap CVE follow-through, no community answers. Don't put this in composer.json for production — vendor the assets or, better, use laravel/ui, blade-ui-kit, or Bootstrap via npm.
• Debugging ported components. When a form renders wrong, compare against three things in order: the Bootstrap docs for your target version, the bundle's original Twig block (to see intent), and your component's rendered HTML. Nine times out of ten the mismatch is a renamed utility class, not logic.
• Extension points worth stealing. The form theme blocks themselves and any bootstrap_* Twig functions are the only genuinely portable ideas. The DI extension and bundle config are not.
• Pin your Bootstrap version explicitly. Because the bundle bundles an old major version, ambiguity here causes subtle layout regressions across the whole app — set it in package.json and document it in the README.
• If you must reference the bundle's assets, load them through a separate <link> in a layout, not through Vite, so they don't get merged into your modern bundle. Keep them isolated and slated for removal.