Zurb Foundation Laravel Package

Technical Evaluation

What the package actually is. laravel-frontend-presets/zurb-foundation is not a runtime library — it is a scaffolding installer. It registers a service provider and an Artisan command that, when invoked, overwrites a Laravel application's frontend baseline: package.json, webpack.mix.js, resources/assets/sass/*, resources/views/layouts/*, and the auth views, replacing the default Bootstrap 4 scaffolding with Zurb Foundation markup and its SCSS/JS pipeline. There is no runtime API surface, no facade, no config file of note. That framing drives everything below, and v2.1.2 does not change it.

What v2.1.2 actually changes. The release note is one line: "Updated composer json for Laravel 6.0 and up." This is a metadata-only release. No source files, views, SCSS, or command registrations are reported as changed. Concretely, it widens the illuminate/support (and related) version constraints so Composer will now resolve the package onto Laravel 6, 7, 8, 9, 10, and 11 applications. It does not restore the php artisan preset command that Laravel 6 removed, and it does not add Vite support, Dart Sass support, or updated Foundation assets. The installability and the functionality have been decoupled: the package now installs cleanly where it cannot function.

Architecture fit: unchanged — poor for greenfield, narrow for legacy. The functional target remains Laravel 5.5–5.8, because the preset mechanism is the only entry point and it was removed in Laravel 6. v2.1.2 changes the addressable install surface (now 5.5 through 11+) without changing the addressable functional surface (still 5.5–5.8). For a product with a "current or current-1" supported-version policy, the package remains out of scope — but the reason shifts from "won't install" to "installs and does nothing," which is a strictly worse failure signature.

Integration feasibility: unchanged in effort, degraded in diagnosability. The underlying cost drivers are untouched by this release: a Foundation for Sites release pinned to circa-2019, a Laravel Mix/Webpack chain, node-sass (deprecated, fails to build on Node 16+ without workarounds), and jQuery for Foundation's JS plugins. What has changed is that the previous, honest failure — Composer refusing to resolve on a modern app — has been removed. A team can now add this package to a Laravel 10 app, see a green composer require, and reasonably conclude it is supported. It is not.

Technical risk: high, and v2.1.2 marginally increases it. The abandonment thesis needs a precise restatement rather than a retraction. There has now been one release since May 2020, and it is a single-line constraint widening with no corresponding functional work — that is a maintenance gesture, not a maintenance cadence. 52 stars and zero dependents are unchanged, meaning still no downstream party exercising the code, filing issues, or patching it. Risk vectors, revised:

• Constraint widening without upper bound. "6.0 and up" is open-ended. The package will resolve onto Laravel 12 and beyond, untested, with no maintainer intent to validate those versions. Every future Laravel major silently expands the blast radius.
• Install-succeeds / command-absent. The most likely support ticket is now "we installed it per the README and php artisan preset foundation doesn't exist" — with a successful Composer log as evidence that it should work.
• Unpatched front-end dependency tree (Foundation 6.x, jQuery, old Sass tooling), unchanged by this release.
• Build reproducibility on modern CI images, unchanged.
• Silent divergence between the scaffolding it writes and current Laravel conventions (Vite, resources/ layout changes, Tailwind-first defaults), unchanged.

Key questions before any spend:

• Is there an actual Foundation design-system mandate, or is this "someone likes Foundation"? Unchanged, and still the pivotal question.
• What Laravel version is the target application on, and what is the upgrade horizon? The answer now matters more, not less — a 6+ target means the package installs but cannot run.
• Does the team understand that v2.1.2 is a Composer constraint edit and not a compatibility fix? Worth confirming explicitly, because the release note reads like the latter.
• Does the existing app already own customized auth/layout views that this preset would overwrite?
• Is the team prepared to fork and own this, and is there a named owner?
• Would a direct foundation-sites npm dependency plus hand-rolled Blade layouts satisfy the requirement with less total cost?

Integration Approach

Stack fit. The package still fits exactly one profile: a Laravel 5.5–5.8 application using Laravel Mix, where Foundation is a hard design-system requirement and the app is not slated for a framework upgrade in the next two quarters. v2.1.2 does not extend this profile — it extends the set of applications that can mistakenly believe they are in it. It does not fit Laravel 9/10/11 (Vite, no preset command), does not fit Livewire/Inertia applications with their own layout scaffolding, and does not fit any team standardizing on Tailwind or Bootstrap.

Recommended path: do not adopt the package; reuse its content. This recommendation is unchanged and is, if anything, reinforced — the release adds no code worth consuming. The value inside the repo remains a few hundred lines of Foundation-flavored Blade and SCSS, which is readable and copyable:

1. npm install foundation-sites directly, plus sass as the compiler.
2. Wire it into the app's existing build — Vite for Laravel 9+, Mix only if the app is already on it.
3. Copy the preset's layouts/app.blade.php, auth views, and _settings.scss into the app as first-party files, reconciled against the app's existing markup.

This gets the design outcome, avoids an unmaintained dependency, and eliminates the "we installed a package that overwrote our views" failure mode.

If the package must be used (legacy 5.x app, short horizon). Fork it into an internal namespace, pin the dependency, and treat it as a one-shot code generator rather than a persistent Composer dependency — install, then remove it from composer.json and commit the generated assets. Pin to v2.1.2 or later so the fork carries the widened constraints, but note the fork inherits the same functional ceiling: 5.8 and below only. If the fork is intended for a 6+ app, budget for reimplementing the command as a standalone Artisan command or a one-off seeder — at which point the fork-and-copy path is cheaper.

Migration path off. Unchanged sequence: (1) inventory which files the preset wrote and which have since been hand-edited; (2) replace node-sass with sass (Dart Sass) and verify the Foundation SCSS still compiles — Foundation 6.x is largely Dart-Sass-compatible but expect @import deprecation warnings; (3) move from Mix to Vite if Laravel ≥9 is on the roadmap; (4) drop the preset from composer.json. Do steps 2 and 3 before any Laravel major upgrade, not concurrently.

Compatibility caveats to validate in a spike. Node version vs. node-sass, Foundation JS plugin initialization order relative to the app's own JS, and whether the preset's view overrides conflict with any auth scaffolding already customized. Add one new check for this release: confirm on the target Laravel version that the service provider registers at all and that the command is discoverable — this is the specific thing v2.1.2 implies but does not deliver. Timebox the spike to two days; if it exceeds that, the copy path wins on cost alone.

Operational Impact

Maintenance: you still inherit the codebase on install. One metadata release after five years of silence is not a support commitment — it is evidence that the maintainer is reachable, and no more. Upstream will not fix a Sass deprecation, a Node upgrade, or a Blade convention change. The one thing v2.1.2 demonstrates is willingness to edit composer.json; it demonstrates nothing about the code paths that actually break. Budget the package as first-party code from day one.

Support. No maintainer triage, no release cadence, no security response path. The v2.1.2 release actively widens the support surface without widening the maintainer's engagement with it, which means the ratio of "apps that can install this" to "apps the maintainer is watching" has gotten worse. If a transitive front-end dependency (jQuery, Foundation 6.x) receives a CVE, there is still no version of this package that will pick up the fix. Mitigation remains a pinned, audited dependency tree and a named internal owner — which is another argument for owning the SCSS/Blade directly.

Scaling. Runtime scaling impact is nil; this is build-time scaffolding. The organizational concern is unchanged and slightly amplified: every additional Laravel app that installs this — now possible on every major version through 11+ — multiplies the number of bespoke, undocumented Foundation build pipelines the platform team supports, and each one fails differently depending on its Laravel version. One app is a snowflake; three is a maintenance program. Standardize on a single Foundation setup (npm + Vite) rather than letting each app install the preset independently.

Failure modes to plan for.

• Install succeeds, command absent on Laravel 6+ — now the most likely and most confusing failure, and materially more likely than before v2.1.2, since Composer no longer blocks it. The success log is the trap. Document this explicitly in any internal guidance that mentions the package.
• Silent view overwrite — the preset writes into resources/views/, clobbering customized auth and layout files with no diff or confirmation. Data-loss-adjacent in a working app; never run it against a dirty tree. (Applies only where the command actually runs, i.e. 5.x.)
• Build breakage on modern Node via node-sass, presenting as CI failures unrelated to application code and often misdiagnosed as an environment issue.
• Foundation JS not initializing — plugin registration order and jQuery availability, surfacing as non-functional dropdowns/modals that pass review because the CSS renders correctly.
• Dependency drift — a composer update or npm update silently shifting Foundation minor versions and changing utility class behavior. Note the widened constraints mean composer update can now also move the package across Laravel majors without a corresponding code change.

Ramp-up. Installation effort remains trivial (under an hour) on 5.x, and is now misleadingly trivial on 6+ — the hour is spent and the outcome is zero. Ownership effort is unchanged. Foundation 6's XY grid and class vocabulary differ meaningfully from Bootstrap, so front-end developers unfamiliar with it need a real ramp — two to three days to productivity, more if the team is Tailwind-fluent and needs to unlearn utility-first habits. The package ships no docs beyond a README, provides no upgrade guides, and v2.1.2 ships no changelog beyond one line, so nothing about this release reduces ramp-up.

Bottom line for the roadmap. v2.1.2 is a one-line Composer constraint edit that makes the package installable on Laravel 6 through 11 without making it functional there. It does not change the recommendation. With 52 stars, zero dependents, no functional change since May 2020, and an open-ended version constraint that will keep widening the mismatch, treat this repository as reference material, not a dependency. Recommend: no adoption; if Foundation is mandated, take the npm-plus-first-party-scaffolding path; if a legacy 5.x app forces the issue, fork at v2.1.2, install once, and remove from composer.json before the next framework upgrade. Add one line to any internal catalog entry: "v2.1.2 permits installation on Laravel 6+ but the preset command does not exist there — installation success is not evidence of support."