- Does frux/foundation6-bundle work with Laravel?
- No. Despite being filed alongside PHP packages, frux/foundation6-bundle is a Symfony2 bundle that registers Foundation 6 assets through Symfony's Assetic-era pipeline and ships Twig form theme templates. Laravel has no bundle registration, no DI extension contract, and no Assetic consumer, so there is no seam through which this package plugs in. Even Laravel's Twig bridge does not load Symfony bundles.
- Can I install this package in a Laravel 11 or 12 app with Composer?
- It will almost certainly fail to resolve. Laravel 9 through 12 constrain symfony/* to ^6 or ^7 and require PHP 8.1+, while a Symfony2-era bundle pins symfony/framework-bundle to the ~2.x line with PHP 5.x and 7.0-era constraints. Composer's solver will refuse the install, and forcing it with --ignore-platform-reqs or aliasing risks dragging end-of-life Symfony components into your dependency tree.
- How do I use Foundation 6 in Laravel with Vite?
- Add foundation-sites to package.json, import the SCSS partials from resources/css/app.css, and initialize the JS plugins you need in resources/js/app.js. Configure Vite with the sass preprocessor if you want to customize Foundation's settings before compiling. That setup delivers everything the bundle nominally provided and takes roughly one developer-day, with no Composer dependency and no legacy framework surface.
- Is Foundation 6 still a good choice for a new Laravel project?
- Foundation 6 is mature but stale, and its JavaScript plugins assume jQuery, which conflicts directly with Laravel's Vite and no-jQuery defaults. Tailwind, current Bootstrap, or Foundation's own newer releases are the more common choices for new work. If your design system is already Foundation 6, that is a real constraint worth naming explicitly rather than treating the package as the requirement.
- What does FruxFoundation6Bundle actually provide?
- It provides Foundation 6 CSS, JS, and icon font assets wired into Symfony's asset handling, Twig form theme overrides so Symfony Form types render Foundation markup, and template helpers for the grid and components. All of that is packaged for Symfony's bundle and service container model. The durable, transferable parts are just Twig templates and static SCSS/JS, which is reference material rather than a reusable dependency.
- How do I get Foundation-styled form markup in Laravel Blade?
- Copy the Twig form theme blocks you need and translate them into Blade components such as x-form.input and x-form.select. Laravel's FormBuilder does not consume Symfony Form types, so the original Twig theme has no consumer in a Laravel app anyway. This is small, bounded work that preserves the design intent without adopting a dependency.
- Do the Foundation 6 JS plugins require jQuery?
- Yes, Foundation 6's JavaScript plugins assume jQuery, which is not part of Laravel's default Vite setup. You can add jQuery to your bundle if you must, but most Laravel teams either drop the plugins that need it or rewrite the interactions with Alpine.js or vanilla JS. That assessment matters independently of this bundle, since the bundle only ships the assets.
- Is frux/foundation6-bundle still maintained?
- There is no validation signal: empty stars, zero dependents, and no issue activity. The target framework itself, Symfony 2.x, reached end of life in November 2018, which is a strong proxy for the bundle's own maintenance state. Before relying on it in any form, check when the repository last saw a commit and whether the tagged branch still resolves.
- What are the alternatives to this bundle for a Foundation 6 design system?
- For Laravel, the practical alternative is the foundation-sites npm package compiled through Vite with sass, registered in resources/css/app.css and resources/js/app.js. For form markup, Blade components or a form macro replace the Twig form theme. If you genuinely need the Symfony bundle integration, you need a Symfony application, not a Laravel one.
- Should I fork the bundle or just rewrite the form themes as Blade components?
- Rewrite them. Forking is only defensible under a documented requirement to stay on Symfony 2.x or to keep the Twig form themes alive in a Symfony app, and even then you inherit an unmaintained dependency with a bus factor of one. Translating the handful of Twig theme blocks into Blade components is bounded work with no ongoing maintenance cost.