kucrut/vite-for-wp
Vite for WP integrates the Vite build tool with WordPress, giving theme and plugin developers fast HMR in development and simple manifest-based asset loading in production. It handles enqueueing scripts and styles with minimal configuration and no build headaches.
Architecture fit. The first thing to flag in any intake review: kucrut/vite-for-wp is not a Laravel package. It is a Composer-installable PHP library scoped to WordPress's asset-enqueue model — it reads a Vite manifest.json, resolves hashed filenames, and calls wp_enqueue_script / wp_enqueue_style, with a development mode that injects @vite/client for HMR. It has no service provider, no facade, no config publishing, and no awareness of Laravel's container or @vite Blade directive. The 7.18 composite score reflects a well-executed, narrowly scoped utility rather than something with broad platform reach.
That means the evaluation question is not "should we add this to a Laravel app" — Laravel already solved this problem with laravel-vite-plugin plus the @vite directive, and this package would be strictly redundant there. The real fit is organizational: if the team operates WordPress surfaces (marketing sites, content hubs, WooCommerce storefronts, legacy client work) alongside Laravel services, this package lets both estates share one Vite build toolchain, one set of frontend conventions, and one CI asset pipeline. That standardization argument is the only durable business case.
Integration feasibility. High, within the WordPress boundary. It is a small library — a few hundred lines — with a single documented integration point in functions.php, and it composes cleanly with existing theme/plugin build setups. Cost to prove it out on one theme is measured in days, not weeks.
Technical risk. Three items dominate:
localhost:3000 asset URLs. A misconfigured staging or production environment silently produces a site that loads nothing — a high-severity, low-probability failure that must be gated in deploy config, not left to developer discipline.Key questions for the intake review. Do we actually own WordPress properties, and how many? Is any WP surface distributed to third parties under a non-GPL license? Who owns the fork if upstream goes quiet? Does the target WP version matrix support the enqueue patterns used (module scripts, translation handling via wp_set_script_translations)? Are there CDN or reverse-proxy constraints that would break HMR websockets for developers?
Stack fit. Position it as a WordPress-ecosystem dependency only. Do not introduce it into Laravel service code, and resist the temptation to use it as a reference implementation for a homegrown Laravel asset resolver — Laravel's native path is better supported. Where value exists is the shared Vite config, shared package.json conventions, and shared CI job templates across both estates.
Migration path. Adopt incrementally per WordPress surface. Start with one theme already using a hand-rolled or wp-scripts/webpack build, since that gives the cleanest before/after comparison on build time and enqueue correctness. Keep the existing build in place behind a branch until the new manifest-based enqueue is verified in staging. Do not attempt a fleet-wide cutover; the package's per-surface integration point makes parallel adoption cheap and reversible.
Compatibility. Verify three axes before pilot approval: PHP version floor versus our supported runtime, WordPress core version floor versus our estate's oldest site, and Vite major version — the manifest location moved to .vite/manifest.json in Vite 5, so any site pinned to Vite 4 needs its config adjusted. Also confirm the dev-server env flag mechanism aligns with how our environments actually inject configuration (.env, wp-config.php constant, container env), because that is where most failed integrations originate.
Sequencing. (1) Confirm the WordPress estate inventory and licensing posture; (2) pilot on one theme, one developer, one sprint; (3) codify the environment-flag guardrail and manifest-presence check as a deploy-time assertion before any second site is touched; (4) only then publish an internal standard and roll out to remaining surfaces. Gate step 4 on step 3 being automated — manual guardrails will not survive contact with a dozen sites.
Maintenance. Low steady-state cost: the library is small, changes infrequently, and version bumps are unlikely to require code changes in consuming themes. The real maintenance load is the Vite upgrade treadmill underneath it, which the team carries regardless of this package. Budget a few hours per Vite major version.
Support. Community-only. GitHub issues, no SLA, no vendor escalation. The practical mitigation is that the codebase is small enough for a senior engineer to read end-to-end in an afternoon, which makes forking viable. Assign a named internal owner before adoption, and record a decision to fork-if-abandoned rather than treating that as an unspoken assumption.
Scaling. Effectively free at runtime — the only per-request work is a manifest read and decode. On high-traffic WordPress installs, memoize or object-cache the parsed manifest rather than re-reading from disk on every page load. Build-time scaling is a CI concern, not a package concern. Multisite and multi-theme estates add configuration surface area but not load.
Failure modes to instrument. Production pointing at the dev server (deploy assertion required); manifest missing or stale after a partial deploy (fail loudly, not silently); base path mismatch behind a subdirectory install or CDN prefix; HMR websocket blocked by corporate proxy or container networking (developer-experience friction, not production risk); script module ordering and React refresh preamble issues with type="module" enqueues; and translation loading for hashed script bundles.
Ramp-up. A developer already fluent in both WordPress enqueue semantics and Vite can be productive in under a day. A developer strong in Laravel/Vite but new to WordPress will lose roughly a week to the enqueue model, dependency arrays, and the dev/prod duality — worth sequencing deliberately rather than discovering mid-sprint. Overall verdict: approve as a scoped, owned WordPress dependency with a mandatory deploy-time dev-mode guardrail; reject any framing that positions it as a Laravel-side component.
How can I help you explore Laravel packages today?