Zurb Foundation Laravel Package

Product Decisions This Supports

• Frontend stack standardization: Choosing Foundation over Bootstrap or Tailwind is a design-system decision with multi-year consequences (component library, grid semantics, accessibility baseline, hiring pool). This preset remains the cheapest way to prototype that choice inside a real Laravel app before committing. v2.1.2 does not change this calculus — it touches composer.json only, no scaffolding, Sass, or Blade output changed.
• Build vs. buy (well, "adopt vs. script"): Still a thin artisan preset shim that swaps Laravel's default Bootstrap scaffolding for Foundation's Sass/XY-grid setup. The real question is "30 minutes wiring Foundation by hand, or depend on a low-traffic package?" — and the answer still flips on lifecycle stage. The new release nudges this toward "just script it": a maintenance commit that only widens a version constraint is a signal the package is kept installable, not kept working.
• Roadmap scoping for legacy surface area: The package's composer constraint now advertises Laravel 6.0 and up, which is wider than the capability it delivers. On Laravel 6+ the preset command is no longer core — it lives in laravel/ui. So the honest roadmap line is: this supports maintenance of existing Foundation-based apps on Laravel 5.x, and the 6.0+ constraint should be read as "will install" rather than "will work." Do not let the version bump pull new-work scoping into scope.
• Use cases it unblocks: Unchanged — rapid internal-tool and admin-panel spinners where the team's design language is already Foundation (e.g. inherited from a Rails/Foundation-era codebase), agency starter kits, and demo/POC builds where brand consistency with an existing Foundation design system beats long-term dependency hygiene.
• Migration triage: The 2020-era release cadence plus this metadata-only bump make it a good forcing function for "what does our frontend preset story look like on Laravel 10+?" (answer: Breeze/Jetstream plus a documented manual Foundation install). Surfacing that in planning beats discovering it mid-sprint — and a version bump that looks like revived support is exactly the kind of thing that gets discovered mid-sprint.

When to Consider This Package

Adopt it when all of the following hold:

• The application is pinned to a Laravel version where the preset command is actually available — Laravel 5.x core, or 6.x with laravel/ui installed and verified. Confirm the command exists before committing, because the package's own constraint no longer tells you this.
• Your org has an existing Foundation design system (tokens, component Sass, XY-grid conventions) and consistency beats novelty.
• The work is greenfield scaffolding or a one-time refresh, not an ongoing dependency you'll need to patch — the output is source files you own, not a runtime library.
• You need accessibility and responsive-grid behavior that Foundation provides out of the box and don't want to hand-roll it.

Look elsewhere when:

• You're on Laravel 6+ and expect this release to mean "now supported." It does not. The constraint widened; the scaffolding workflow did not. A widened constraint is arguably a worse failure mode than a hard composer conflict, because the install now succeeds and the command silently isn't there.
• You want Tailwind (the current Laravel default and the direction of the ecosystem) — Breeze gives you a maintained, first-party path.
• Your team judges dependency hygiene by maintenance recency. One composer-metadata commit since 2020 is not a maintained dependency; expect it to fail procurement or a security-review checklist on principle, even though the real risk surface here is genuinely small.
• You'd be the first adopter in your org and the only thing you need is Foundation's Sass build — installing foundation-sites via npm and importing it into resources/sass/app.scss is roughly an hour of work and removes the dependency entirely. Treat the package's repo as reference implementation, not a dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost developer-convenience tool, not a strategic platform bet. It lets a team already standardized on the Zurb Foundation design system spin up a Laravel app with their house styles in minutes instead of hours, which is worth real money across a dozen projects. It carries no runtime or security exposure — it generates frontend boilerplate at project creation and then gets out of the way. A patch shipped recently, but read it correctly: it only updated a version constraint, it did not add capability or modernize the build tooling. Recommendation: allow it for legacy work, do not standardize on it, and fund a short spike to document the manual Foundation setup so we're not dependent on an unmaintained package for future projects.

To engineering: It's a thin artisan preset shim — it copies in a Foundation-flavored webpack.mix.js, Sass entrypoint, and Blade layouts, replacing Laravel's Bootstrap defaults. v2.1.2 is a composer.json-only change widening the constraint to Laravel 6.0+, so pin your expectations accordingly: the install will succeed on 6+, but preset is provided by laravel/ui there, not core, and the 2020-era Mix/Webpack scaffolding predates Vite. Because the output is vendored into your repo, ongoing risk is essentially zero; the risk is a successful install that produces nothing. Two asks: (1) if you use it, verify php artisan preset is registered first, commit the generated files, and treat the package as a require-dev one-shot then remove it; (2) if you're on a current Laravel version, spend the hour doing the Foundation install manually against Vite — you'll get a better result than retrofitting a 2020 preset.