Serving Multiple Vite Frontends in Laravel: Mastering Directory Structure and Manifests

As a senior developer working within the Laravel ecosystem, managing complex frontend setups—especially when dealing with multiple applications or micro-frontends built with Vite—often introduces tricky configuration hurdles. The issue you are facing regarding the "Vite manifest not found" error stems from how the laravel-vite-plugin and the underlying Vite build system expect asset manifests to be located relative to the public directory.

This post will dive deep into how to correctly configure your Vite projects to handle separate frontend applications (app and admin) within a single Laravel context, focusing on managing build outputs and serving multiple frontends efficiently.

Understanding the Vite Manifest Conflict

The error you encounter—"Vite manifest not found"—occurs because the Laravel Vite plugin, by default, assumes that the compiled assets (the manifest file) will reside in a specific location within your public directory (usually public/build). When you configure your Vite build to output files into custom directories like public/js/app and public/js/admin, Vite generates the manifest there, but Laravel's asset bundling mechanism doesn't automatically scan all these disparate locations unless explicitly told.

The core problem is not just where the files are saved, but how the entry points and manifest generation are managed across multiple projects. We need to leverage Vite’s ability to handle multiple entry points gracefully.

Strategy 1: Customizing Vite for Multiple Entry Points

Instead of trying to force the Laravel plugin to merge two separate builds into one manifest (which often leads to complexity), the cleanest approach is to treat your app and admin frontends as distinct, independent Vite projects that coexist within your larger application structure.

Step 1: Separate Vite Configurations

You should maintain separate vite.config.js files for each frontend if they have fundamentally different dependencies or build processes.

Example Structure:

laravel-project/
├── resources/
│   ├── js/
│   │   ├── app/        <-- Frontend A source
│   │   │   └── main.jsx
│   │   └── admin/      <-- Frontend B source
│   │       └── main.jsx
├── public/
├── vite.config.js     <-- Main Laravel Vite config (for bootstrapping)
├── vite.config.app.js  <-- Specific config for the 'app' frontend
└── vite.config.admin.js <-- Specific config for the 'admin' frontend

Step 2: Adjusting Build Outputs and Manifests

In your individual Vite configurations, you explicitly define where the output goes. This bypasses the need for the main Laravel plugin to manage both simultaneously in a single manifest file.

For your app project (vite.config.app.js):

// vite.config.app.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
    plugins: [react()],
    build: {
        outDir: 'public/js/app', // Explicitly define the output directory
        rollupOptions: {
            input: 'resources/js/app/main.jsx',
        },
    },
});

For your admin project (vite.config.admin.js):

// vite.config.admin.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
    plugins: [react()],
    build: {
        outDir: 'public/js/admin', // Separate output directory
        rollupOptions: {
            input: 'resources/js/admin/main.jsx',
        },
    },
});

Step 3: Serving the Assets in Laravel Blade

Since you have separated the builds, you must now instruct your main Laravel application (and its Blade views) to load both sets of assets independently. You will reference the compiled files directly in your main layout, rather than relying on a single monolithic manifest generated by the plugin.

In your main layout file (resources/views/layouts/app.blade.php), you would link the assets separately:

<!-- Assets for the main application -->
@vite('resources/js/app/main.jsx') 

<!-- Assets for the admin panel (loaded separately) -->
<script type="module" src="{{ asset('js/admin/main.jsx') }}"></script> 

By using @vite() only on the specific entry point you need, and manually referencing the other build directory, you gain full control over the routing and manifest handling for each separate frontend. This approach aligns well with modern practices advocated by the Laravel community, where modularity is key to scalability (as seen in the principles discussed on laravelcompany.com).

Conclusion

Managing multiple Vite projects within a Laravel application requires moving away from a single, monolithic manifest strategy. The most robust solution involves treating each frontend (app and admin) as an independent build unit, each with its own configuration file and explicitly defined output directory. By controlling the build.outDir in each specific Vite configuration, you ensure that your assets are correctly placed, and you manage the serving process directly within your Blade templates. This gives you the necessary flexibility to scale your application without running into conflicts with asset manifest errors.