thepublicgood/vitamin
Vitamin is a Laravel package for application health checks. Define checks for the database, cache, queue, storage, and other services, then expose a simple endpoint so uptime monitors and teams can quickly verify your app is healthy.
Vitamin is a bridge between Vite's dev server and Laravel's Blade/Inertia rendering pipeline. It predates laravel-vite-plugin, so it is the thing you reach for when you inherit a project that was scaffolded in early/mid-2022 or has explicit vitamin calls in its views.
As of v1.1.0 the package explicitly supports Vite 3 (its first release since Aug 2022, mostly dependency fixes), so pin your JS toolchain accordingly — see Gotchas before you npm install anything newer.
Minimal steps:
composer require thepublicgood/vitamin:^1.1
php artisan vendor:publish --provider="TPG\Vitamin\VitaminServiceProvider"
config/vitamin.php, which typically exposes an entrypoints array (e.g. resources/js/app.js, resources/css/app.css) and paths.vite.config.js (the package relies on a normal Vite config with the entrypoints mirrored from config/vitamin.php). On v1.1.0 target the Vite 3 line:
npm install -D vite@^3
resources/views/app.blade.php:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
@vitamin
</head>
<body>
@inertia
</body>
</html>
npm run dev
php artisan serve
First use case to verify: load any Inertia page in NODE_ENV=development and confirm script tags point at the Vite dev server (localhost:3000-ish) with HMR working. Then npm run build and confirm the same Blade directive swaps to manifest-backed assets/... URLs. If you are upgrading an existing install to v1.1.0, re-run step 5 both ways — the dependency fixes can change how the bridge resolves the manifest and dev server, so re-verify rather than assuming a drop-in.
Directive-first rendering. The core pattern is a single @vitamin (or the underlying helper) in your root Blade layout. Everything else — module preloads, CSS, the Inertia client entrypoint — is derived from the entrypoints in config/vitamin.php. This means adding a new entrypoint is a config change plus a Vite config change, not a Blade change.
Environment-aware output. In dev, Vitamin reads from the running Vite dev server and emits ES module script tags. In production it reads the Vite manifest (public/build/manifest.json or similar) and emits hashed asset references. Pattern: keep the directive in the layout, never hardcode <script> tags for app bundles.
Inertia page resolution. Because Inertia's root template is just Blade, the integration is essentially "put @vitamin in app.blade.php." You do not need a Vitamin-aware Inertia adapter; the client-side createInertiaApp in resources/js/app.js is standard.
Multi-entrypoint apps. For an app with, say, a separate admin bundle, list both in config/vitamin.php. Vitamin emits tags for both; Vite builds both. Keep the entrypoint names identical across the PHP config and vite.config.js build.rollupOptions.input.
Per-environment overrides. Typical pattern is a local/staging/production split in config/vitamin.php, with staging occasionally pointing at a built manifest while production uses the normal path. Useful if you deploy preview builds.
CI/build pipeline. Standard sequence: npm ci && npm run build && composer install --no-dev && php artisan migrate --force. Vitamin only needs the manifest present at request time — it does not shell out to Node. Since v1.1.0 fixes dependency resolution, keep package-lock.json and composer.lock committed so the build host resolves the exact same Vite 3 / bridge combination you tested locally.
Integration tip (Laravel Mix → Vitamin migration). If you are coming from Mix, the mechanical change is: delete webpack.mix.js, add a Vite config that lists the same entries, and replace @mix(...) / mix() helper calls in app.blade.php with @vitamin. The Inertia client code is unchanged.
v1.1.0 is a maintenance bump, not a revival. It adds Vite 3 support and clears out dependency bugs, but it is still not tracking current tooling: no Vite 4/5/6 support, and the first-party laravel-vite-plugin + @vite Blade directive covers everything Vitamin does and is actively maintained. Treat Vitamin as a migration source, not a destination. On any new project, do not install Vitamin. On legacy projects, plan a migration: replace the config file with a standard vite.config.js, swap @vitamin for @vite([...]) in your layout, and remove the package. The Inertia layer needs zero changes.
Pin Vite to the 3.x line while you are on Vitamin. The release explicitly targets Vite 3. Dropping in Vite 4+ (let alone 5/6) means the manifest shape and dev-server handshake may drift out from under the bridge, and the package is not going to ship a fix for it. If your app already needs a newer Vite, that is your signal to migrate to @vite rather than to upgrade Vitamin.
Dependency fixes can change resolution on upgrade. "Fixed a bunch of foolish dependency bugs" means the constraint set moved. After composer update thepublicgood/vitamin, clear caches (php artisan config:clear && php artisan view:clear) and re-verify both dev and a real npm run build — do not assume the old lockfile still agrees with the new constraints.
Dev server must be running. In development, Vitamin will fail (or emit broken script tags) if npm run dev is not up. If pages render blank white in local dev, that is the first thing to check — not your Inertia page component.
Manifest staleness is the classic production bug. In production, if the manifest is missing or out of date, you get a broken page or an exception. Common causes: forgetting to run npm run build in the deploy script, building on a different machine than the one serving, or a deploy that clears public/build but ships a cached Blade view. Debug by checking that the file Vitamin expects actually exists and contains the entrypoint key.
Blade view caching after config changes. Laravel caches compiled views independently of config/vitamin.php. If you edit the entrypoint list and production still emits the old scripts, run php artisan view:clear. In dev this is rarely an issue; in staging/prod it bites.
Entrypoint name drift. Vitamin matches entrypoints by string between PHP config and the Vite build input. A typo produces a silent "no script tag emitted" rather than a hard error. Verify by inspecting rendered <head> output, not the build log.
Nested/aliased asset paths. If you configure a custom build.outDir or a custom assetsDir, make sure the path you configured in config/vitamin.php matches what Vite actually writes. The package does not probe multiple candidate paths. Vite 3's default outDir is not public/build, so be deliberate about setting it.
HMR websocket in Docker/VM setups. Because Vitamin forwards the Vite dev client, HMR can fail when the browser cannot reach the Vite server's host:port (e.g., Docker port forwarding, remote dev). Set Vite's server.host and server.hmr.host/clientPort explicitly in vite.config.js; Vitamin itself does not control this. Vite 3 uses server.hmr.clientPort rather than the older port key, so copy config snippets from Vite 3 docs, not from 2.x blog posts.
Extension points are thin. The service provider is small; if you need custom script tag attributes (nonce, crossorigin, type), the practical extension point is the Blade template — render @vitamin inside a controlled <head> and post-process elsewhere rather than patching the provider, since future Laravel upgrades will assume @vite.
Don't mix @vitamin and @vite in the same layout. You will get duplicated or conflicting asset tags during a migration. Do a clean swap per environment, not per branch, so HMR and prod builds stay consistent.
Testing tip. For feature tests that render your Inertia root, either fake the manifest/vite state through Laravel's fake hooks (available on the modern @vite path) or avoid asserting on asset tags — assert on assertInertia and rendered props instead. Asset-tag assertions against a barely-maintained package are not worth maintaining.
How can I help you explore Laravel packages today?