Foundation6 Bundle Laravel Package

Product Decisions This Supports

• Front-end standard for legacy Symfony surfaces: The one genuine decision this informs is whether to adopt Foundation 6 as the presentation layer for an existing Symfony 2.x/3.x application — admin panels, back-office CRUD, internal tools — where server-rendered Twig views and a documented grid/form baseline let a backend-heavy team ship UI without a dedicated frontend hire.
• Build vs. buy on integration glue: This is "buying" the plumbing — Foundation asset registration plus Twig form themes — instead of wiring it yourself. Realistically the win is days, not weeks; scope the credit accordingly and don't let it anchor a roadmap theme.
• Form consistency as a product-quality lever: A shared form theme means every CRUD screen renders predictably, collapsing per-feature UI debates and review cycles. This is a real reduction in delivery friction on internal tools where speed beats polish.
• Legacy modernization sequencing (the decision that actually matters): Adopting it is a proxy vote to keep the Symfony 2.x/3.x line alive longer. Declining it forces a migration conversation. Surface it as a timeline decision, not a library preference.
• Explicitly not a Laravel decision: Despite being filed as a Laravel/PHP package, it is a Symfony2 bundle with no bundle system, DI extension, or Assetic seam in Laravel. It does not inform Laravel feature, roadmap, or dependency decisions, and should not appear in a Laravel backlog except as a "rejected — wrong ecosystem" note.
• Roadmap de-prioritization: It standardizes presentation only. Keep it out of pricing, packaging, API, and data-model conversations.

When to Consider This Package

Adopt only when all of these hold:

• The application is on Symfony 2.x–3.x with Assetic or early Webpack Encore, and no migration is funded in the next 12 months.
• You specifically want Foundation 6. If the requirement is "any decent grid," a CSS-only or Encore-native path is lower risk.
• The team is backend-heavy with no frontend specialist, so a Twig-first, no-build-step approach has real value.
• Someone has read the source and confirmed it does meaningfully more than register two asset paths and a form theme. Thin wrappers are cheap to replicate — verify before adopting.

Look elsewhere when:

• The project is Laravel. Not a fit on any axis: no bundle system, no Assetic, and Composer will refuse to resolve a Symfony 2.x-era constraint alongside Laravel 9–12's symfony/* ^6/^7 and PHP 8.1+. The correct Laravel equivalent is foundation-sites via npm + Vite, with Blade components replacing the Twig form theme.
• You are on Symfony 4+ (or 5/6/7) — use symfony/webpack-encore with npm i foundation-sites, or Symfony UX/Twig components. This bundle targets a framework line end-of-life since 2018.
• Adoption signal matters. Zero stars, zero dependents, zero package score: no community validation, no security response channel, no compatibility guarantees. Treat it as unvetted third-party code you will own.
• You need accessibility conformance, RTL, or design-token theming — Foundation 6 is aging relative to current design-system tooling, and an unmaintained wrapper won't close that gap.
• You have compliance or audit obligations (SOC 2, accessibility audits, SBOM). An abandoned integration layer is a liability you must fork or replace.

How to Pitch It (Stakeholders)

To executives: A small, low-cost way to give a legacy Symfony application a consistent, documented UI baseline — useful for internal tools and back-office screens where speed beats polish. It is not a strategic platform bet: no meaningful adoption, no active maintainer signal, and it targets a Symfony version that has been end-of-life since 2018. Approve it as a tactical shortcut with a known expiry date — or, better, decline it and record the decision. It has no applicability to our Laravel work; if it appears in a Laravel backlog, that is almost always a developer carrying over habits from a prior Symfony project.

To engineering: A thin Symfony 2-era bundle that wires ZURB Foundation 6 assets and Twig form themes into an existing Symfony stack. Realistic adoption needs a short spike to confirm it works on our Symfony/PHP versions, then version pinning plus vendoring or forking so we control the code. The exit path is straightforward — foundation-sites via Webpack Encore (or Vite, on Laravel) plus a local form theme — so budget that migration as the true cost of using this at all. Expect it to hard-fail Composer resolution on modern stacks, to carry transitive EOL Symfony components that composer audit will flag, and to assume jQuery-based Foundation plugins. Bottom line: mark as evaluated and rejected. The stated need — Foundation 6 styling with consistent form markup — is real and cheaply met through npm and local templates; this package is a Symfony2 artifact with no Laravel surface area, no maintenance, and no community, and introducing it trades fetchable assets for a permanent liability.