Wind Laravel Package

Technical Evaluation

Architecture fit. Wind is not what its listing copy claims. The description advertises "reusable Blade components for Tailwind," but the artifact is a Filament plugin: a public contact form on the front end, a submissions table and a Livewire-backed review screen inside the Filament admin panel. That mismatch matters to a TPM because it narrows the fit test from "any Laravel app with Tailwind" to a single, specific architecture: Laravel + Livewire + Filament, where the admin panel is the accepted system of record for inbound messages. If the panel isn't the destination for leads, this package is the wrong shape and no amount of configuration fixes it.

Integration feasibility. High, conditional on versions. The package tracks Filament majors, so adoption is a version-matrix exercise before it is an engineering one. Three facts decide whether this is a twenty-minute install or a dead end:

1. composer show filament/filament livewire/livewire laravel/framework on the target app.
2. The require block in the package's composer.json on the exact tag intended for install — a v4-era release will not install into a v3 panel.
3. The PHP constraint, which is the usual silent blocker on older CI images.

Install is composer require plus four publish tags (wind-config, wind-migrations, wind-views, wind-translations) and a WindPlugin::make() registration in the panel provider. Publish tag names drift between majors; if a tag returns "no publishable resources," run the interactive publish and select the provider. None of this is architecturally invasive — it's a table, a route, a Livewire component, and a Filament resource.

Technical risk. The risk is continuity, not code quality. ~35 stars, zero dependents, MIT, single maintainer, issue-tracker-only support, and a PR history dominated by dependabot bumps plus translation and docs chores. Read that as maintenance-mode stewardship, not active product investment. The mitigating fact is the size of the artifact: a competent Laravel developer rebuilds the equivalent — form, persistence, review table, notification — in one to two days. That number is simultaneously the buy case, the fork cost, and the escape-hatch estimate. A dependency with a two-day replacement cost is a low-stakes either/or, not an architecture commitment. Treat it accordingly: pin the exact version, wrap it in a single swap point, and do not standardize on it across multiple products.

Key questions for the decision record.

• Is the Filament panel the intended home for these messages, or a convenient temporary one? If a CRM or helpdesk is the long-term destination, adopt Wind only as a capture layer with an explicit migration plan.
• What is the volume and value of a lost submission? Low-volume, recoverable, "someone will follow up eventually" traffic tolerates this. Anything with an SLA or a sales owner does not survive silent lead loss.
• Do we have a named owner for the inbox? Capture-and-review without an owner produces a backlog nobody notices for three weeks — a product failure that no package can prevent.
• Which Filament major are we on, and when is the next bump? Never adopt in the same release train as a Filament v3 → v4 upgrade.
• Have we decided the PII posture — retention window, export format, deletion-on-request handling, and who holds panel access — before go-live rather than after a subject access request?
• Is "capture and review" sufficient for the next two quarters, or will routing, assignment, and SLA tracking be needed within one?

Integration Approach

Stack fit and compatibility. The install path is fixed and short, but every step has a common failure that looks like a package bug and isn't: plugin not appearing in navigation (panel provider registration), form rendering but silently no-op submission (stale published Filament/Livewire assets — run filament:assets / livewire:assets and confirm cache-busting per release), config edits having no effect (config cache; run php artisan config:cache after editing config/wind.php in any cached environment), and duplicate migration stubs after a second publish. The debugging order that resolves the overwhelming majority of "the plugin isn't working" reports without reading source: (1) panel provider registration, (2) php artisan about version matrix vs the package's composer.json, (3) asset staleness, (4) config cache, (5) published-view divergence.

Sequencing. Prove the loop end-to-end in a scratch app before touching the real one — it costs an hour and eliminates every "is it me or the package" question later:

1. Scratch-app spike. Install pinned, publish, register, drop the form on a page, submit, confirm row persists, confirm notification lands, confirm it appears in the panel.
2. Pin and publish for real. composer require lara-zeus/wind:^5.0 — pin, don't float. Publish config, migrations, translations; publish views only under duress.
3. Own the schema. Move the migration out of vendor into database/migrations with a real timestamp, then make all further schema changes with your own migrations. Add an index on created_at now — you will sort and filter by it. Note in the runbook that a future vendor:publish will drop a duplicate stub that must be deleted.
4. Establish the swap point. Content pages reference @include('partials.contact-form') and nothing else; that partial contains the package tag. One route name, one partial, one place to replace. When the package is abandoned or outgrown, you replace a six-line file and zero content pages.
5. Configure, don't fork. Labels, redirect target, notification recipient, and layout come from config/wind.php and language overrides. Anything under vendor/ is maintenance you didn't budget. If config can't meet the requirement, prefer a model observer or wrapper component over a view override — published views win permanently and upstream fixes never reach you.
6. Hook downstream work at the model, not the package. Submission::created(fn ($s) => SyncLeadJob::dispatch($s)->afterCommit()); — afterCommit() prevents queued jobs firing for rows whose transaction rolled back.
7. Fix persistence-versus-delivery ordering. Read the submit method and confirm the row is written before mail is attempted and that a mail exception doesn't propagate. If delivery is synchronous, move it to a queued notification or fire it from the created listener. A contact form that 500s when SMTP is slow is worse than one with no notification.
8. Gate the resource explicitly. Default Filament authorization is permissive. Submissions are PII — "everyone with a panel login can read customer emails" is a review finding. Add a policy or canViewAny check, and if multiple panels exist, register the plugin only in the one that should see the inbox.
9. Guard the public endpoint. Treat it as an unauthenticated write endpoint, because that's what it is. Rate-limit at the route or edge (not just in the component), add a honeypot or captcha to the partial, and rely on Laravel validation for sanitization.
10. Test the failure, not just the path. Livewire::test() the component, assertDatabaseHas() the submissions table, Notification::fake() for the mail assertion — plus one test asserting the row still exists when the notification transport throws. That last test is the one that protects against silent lead loss.

Extend in Filament, not upstream. Read/unread state, assignment, bulk CSV export, "mark all as read" — these are table actions and column toggles in your own resource subclass. The package gives a starting resource; Filament gives the rest. Do not wait for the maintainer.

Operational Impact

Maintenance. The real upgrade event is not a Wind release, it's a Filament major. Budget roughly a day a year and re-test the form end-to-end on every Filament bump. Keep the version pinned to an exact tag, keep published-view divergence documented with the version it diverged from, and never re-publish migrations over a table you already own. Ongoing maintenance otherwise approaches zero, which is exactly the profile of a dependency that quietly rots when it does break.

Support. There is no vendor. Support is the issue tracker, a single maintainer, and your own team. Assume no SLA and no fix timeline. That's acceptable for a two-day replaceable component and unacceptable if the channel becomes business-critical — which is the trigger, not a feeling, for invoking the fork-or-rebuild decision. Write that decision down now, with the trigger conditions, so it isn't relitigated mid-incident.

Scaling. The load risk isn't database throughput; a contact form's write volume is trivial. The risks are spam-driven table bloat, exhausted mail quota, and a noisy dashboard that trains operators to ignore it. Rate-limit at the edge rather than only in the component, and watch row growth for the first month. Volume also drives the product question: the moment submissions need owners, SLAs, or routing, the package's capture-and-review scope is exhausted and the CRM/helpdesk conversation starts.

Failure modes, ranked by likelihood × damage.

• Silent lead loss — the realistic headline failure. Not a 500, not an outage: messages never persisted or never emailed, unnoticed for weeks. Mitigated by write-before-mail verification, queued delivery, and an alert on submission-count dropping to zero.
• Unowned backlog — capture works, nobody triages, inbound goes stale. A process failure the package can't solve, mitigated by naming an owner and a review cadence at launch.
• Stale assets — form renders but validation or submission no-ops. Most common "worked locally" symptom with Filament plugins; fix with an asset build step in the deploy pipeline.
• Duplicate migration stubs — second publish fails or re-creates the table.
• Config-cache invisibility — configuration changes that appear not to apply.
• Filament major breakage — install or runtime failure at upgrade time, absorbed by the annual budget line.

Ramp-up. A Laravel developer is productive with Wind in half a day; the actual ramp is Filament familiarity, not package knowledge. The investment that pays back is a one-page runbook written at launch: where the form lives, where rows go, how to export, how to disable the form, who watches volume, and the debug order for "the plugin isn't working." Pair it with a PII decision record — retention window, export format, deletion-on-request handling, and the named audience for panel access — because none of that ships with the package and all of it becomes urgent retroactively.

Bottom line for the roadmap. Wind buys back roughly a day of engineering on a table-stakes capability and lets the sprint go to differentiation. Frame it as capacity purchased, not a platform adopted: pin it, wrap it in one partial, own the schema, gate the PII, alarm on silence, and keep the rebuild estimate on the shelf.