app.js or throw npm errors in fresh installations due to missing dependencies, incorrect manifest paths, or version mismatches between Vite and Mix. This guide resolves these specific compilation failures by verifying your package structure, clearing caches, and ensuring your environment matches the Laravel version you are running.
Understanding Build Tool Evolution in Laravel
The confusion surroundingapp.js not found typically stems from the transition between Laravel Mix and Vite. Older Laravel versions (prior to 9) relied on Webpack via Laravel Mix. Newer versions default to Vite for faster, more modern asset compilation. If you are seeing references to mix.mix, it is a typo; the correct helper function is mix() in Mix projects or vite() in Vite projects. Identifying which tool your project uses is the first critical step in troubleshooting.
In a standard Laravel 10+ installation, the resources/js/app.js file is compiled into public/build/manifest.json. If this manifest is missing or corrupted, the application cannot locate the JavaScript assets. Conversely, in legacy projects using Mix, the output is usually public/js/app.js. Mixing up these paths leads to the "not found" error during runtime. For broader context on resolving general npm issues that might underlie these specific framework problems, see our guide on Troubleshooting npm Errors in Node.js for Beginners.
Verifying Dependencies and Installation
Before diving into configuration files, ensure that all necessary packages are installed. A common cause of failure is an incompletenpm install or yarn install process. Always run the installation command from the root directory of your Laravel project.
- Navigate to your project root in the terminal.
- Run
npm installto install all dependencies listed inpackage.json. - If you use Yarn, run
yarn installinstead. - Check for any peer dependency warnings or errors in the terminal output.
node -v. If your version is outdated, consider using a version manager like nvm to switch to a compatible release. This ensures that native modules compile correctly against your system libraries.
Configuring Vite for Modern Laravel Projects
For Laravel 9 and above, Vite is the default build tool. The configuration resides invite.config.js. Ensure that the base path is correctly set. By default, it should be '' or '/' depending on your deployment subdirectory.
Open vite.config.js and verify the following settings:
export default defineConfig({
plugins: [
laravel({
input: ['resources/css/app.css', 'resources/js/app.js'],
refresh: true,
}),
],
});
If the input array does not point to resources/js/app.js, Vite will not compile your entry point. After verifying the config, clear the cache and rebuild the assets. Run npm run dev for development or npm run build for production. If the build succeeds, check the public/build directory to confirm that manifest.json and the JS bundle exist.
Configuring Laravel Mix for Legacy Projects
If you are maintaining an older Laravel project that still uses Mix, the setup differs slightly. The configuration is located inwebpack.mix.js. Ensure that your mix call includes the correct paths.
mix.js('resources/js/app.js', 'public/js')
.sass('resources/sass/app.scss', 'public/css');
Notice that the output directory is public/js. Your Blade templates must reference this exact path using the mix() helper. If you recently upgraded Laravel but kept the old Mix configuration, ensure that your package.json scripts are updated to reflect the correct commands, such as npm run watch or npm run prod.
Clearing Caches and Resolving Path Issues
Sometimes the code is correct, but cached data prevents the application from reflecting changes. Laravel caches configuration and view files, which can lead to stale asset references.- Clear the config cache with
php artisan config:clear. - Clear the route cache with
php artisan route:clear. - Clear the view cache with
php artisan view:clear. - Remove the
public/builddirectory manually if you suspect corruption in the Vite manifest. - Restart your local server or development environment.
@vite directive rather than {{ mix() }}. Using the wrong directive in a Vite-enabled project will result in broken asset links. For example:
<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
<head>
@vite(['resources/css/app.css', 'resources/js/app.js'])
</head>
<body>
...
</body>
</html>
Using {{ mix() }} in this context will look for the old Mix manifest structure, causing the "not found" error. Ensure consistency between your build tool configuration and your template directives.
Frequently Asked Questions
Why is my public/build folder empty after npm run build?
This usually indicates that Vite encountered an error during compilation but did not display it prominently. Check your terminal output for syntax errors in your JavaScript files or missing imports. Ensuring your vite.config.js points to existing source files is essential for generating the output.
Can I switch from Vite back to Laravel Mix in a new project?
While technically possible, it is not recommended for new projects as Vite is the current standard. Switching requires uninstalling Vite packages, installing Laravel Mix dependencies, and rewriting your package.json scripts and webpack.mix.js configuration. It adds unnecessary complexity without providing performance benefits over Vite.
What causes "Module not found: Can't resolve '@vue/compiler-sfc'"?
This error occurs when Vue-specific dependencies are missing from your node_modules folder. Running npm install again typically resolves this. If the issue persists, delete the node_modules folder and package-lock.json file, then reinstall all dependencies to ensure a clean state.
How do I debug why npm run dev fails silently?
Add the --verbose flag to your command, such as npm run dev --verbose. This provides detailed logging about which plugin or loader is failing. Additionally, check if any other processes are using port 5173, which is the default Vite server port, as conflicts here can cause silent failures.
Is it safe to ignore npm audit warnings during installation?
It is generally safe to proceed with development despite low-severity warnings, as they often relate to indirect dependencies that do not affect functionality. However, high-severity security vulnerabilities should always be addressed. Use npm audit fix to automatically resolve fixable issues before deploying to production.