kaiseki / wp-vite

1.1.0 2026-11-03 18:07 UTC

Requires

• php: ^8.2
• guzzlehttp/guzzle: ^7.4.5
• inpsyde/assets: ^2.8
• kaiseki/config: ^2.0
• kaiseki/wp-env: ^1.0
• kaiseki/wp-hook: ^2.0
• psr/container: ^1.1 || ^2.0

Requires (Dev)

• bnf/phpstan-psr-container: ^1.1
• kaiseki/php-coding-standard: ^1.0
• maglnet/composer-require-checker: ^4.0
• php-stubs/wordpress-stubs: ^6.2
• phpstan/extension-installer: ^1.4
• phpstan/phpstan: ^2.0
• phpstan/phpstan-phpunit: ^2.0
• phpstan/phpstan-strict-rules: ^2.0
• phpunit/phpunit: ^11.0
• roave/security-advisories: dev-latest
• roots/wordpress-core-installer: *
• roots/wordpress-no-content: @stable
• szepeviktor/phpstan-wordpress: ^2.0

MIT

• Kaiseki
• David Mondok
• Wolfgang Schaefer

Published on Packagist.org on 2026-11-03 18:09 UTC

README

Companion module for inpsyde/assets that registers the scripts and stylesheets emitted by a Vite build from its manifest.json, with transparent hot-module-reload support against the Vite dev server.

It wires three kaiseki/wp-hook HookProviderInterfaces through ConfigProvider:

• ViteAssetManager — reads each configured Vite manifest, turns every entry chunk (and its CSS imports) into an inpsyde/assets Script/Style, and registers them on AssetManager::ACTION_SETUP.
• ViteClientScriptRenderer — injects the @vite/client HMR script into wp_head/admin_head when the dev server is hot.
• OutputFilterRegistry — registers the configured inpsyde/assets output filters.

Installation

composer require kaiseki/wp-vite

Requires PHP 8.2 or newer.

Usage

Register ConfigProvider with your laminas-style config aggregator and provide the vite config slice. The Config builder offers a fluent API for assembling that slice:

use Kaiseki\WordPress\Vite\Config;
use Kaiseki\WordPress\Vite\AssetFilter\ScriptFilter;

$vite = (new Config())
    // Path to a Vite build manifest; pass true for the hot (dev-server) variant.
    ->addManifest(get_stylesheet_directory() . '/dist/.vite/manifest.json')
    // Default filters applied to every script / style asset.
    ->addScriptsFilter(ScriptFilter::create()->forFrontendLocation())
    // Per-entry filter, keyed by the manifest entry name.
    ->addScriptFilter('resources/main.ts', ScriptFilter::create()->withDependencies('jquery'))
    // Vite dev-server connection used for hot-reload detection.
    ->setViteServerHost('localhost')
    ->setViteServerPort(5173)
    ->enableAutoLoad();

return [
    'vite' => $vite->toArray(),
    'hook' => [
        'provider' => [
            \Kaiseki\WordPress\Vite\OutputFilterRegistry::class,
            \Kaiseki\WordPress\Vite\ViteAssetManager::class,
            \Kaiseki\WordPress\Vite\ViteClientScriptRenderer::class,
        ],
    ],
];

Block editor canvas

Since WordPress 7.1 the block editor content always renders in an iframe. Assets for the block editor UI stay on forBlockEditorLocation() (enqueue_block_editor_assets), but they do not reach the iframe. Styles and scripts for the content itself use forBlockEditorCanvasLocation(): it enqueues on enqueue_block_assets, which WordPress copies into the iframe, and only in the admin, because that hook also runs on the frontend. A canEnqueue() condition still applies on top.

->addStyleFilter('resources/editor.scss', StyleFilter::create()->forBlockEditorCanvasLocation())

ConfigProvider::__invoke() ships sensible defaults (an empty vite config plus the dependency aliases and factories) — merge it into your aggregator so the providers resolve from the container. Each asset is loaded from the Vite dev server when it is reachable, and falls back to the built file URL otherwise.

Development

composer install
composer check   # check-deps, cs-check, phpstan

License

MIT — see LICENSE.