Im creating a website using Laravel + Inertia + Vue js, running "npm run build" creates a build folder in public directory which its made up of a manifest.json and a assets folder.
When i search how to use this build and deploy it on a server every search results talks about the fact that "npm run build" actually creates an index.html in a /dist folder along with other files.
How come i get a different result when running the same script? Also when running "npm run serve" i get an error when opening the localhost saying "Cannot GET /", where as in every tutorial i have seen related to running this script after building works just fine and i dont understand why.
When you run npm run build, it will create the needed files to run in production.
You don't nee to do anything else.
For your second question, you probably mean npm run dev and not npm run serve.
No matter you are in development or in production, if you get an error when trying to get the / route, that means that the route perhaps doesn't exist.
Have you checked the existing routes in the routes/web.php file ?
@vincent15000 Okay, i think i found the solution. http://127.0.0.1:4173/ doesnt work, but if i go into the xampp server(the one i use when using npm run dev )it shows the build.
My last question i have is: after i run npm run build , how do i connect this build to a database if there is no .env file created with the build?
@BuenosAires Have you perhaps cached your routes ? This is not recommended in development, but if you have cached the routes, you have to refresh the cache by running php artisan route:cache.
When you run npm run build, you have nothing else to do, you just push your code on the server and it will run. All database credentials and other datas in the .env file are managed by Laravel in the backend.
That's the strength of InertiaJS.
@BuenosAires and @vincent15000 always turn debug mode to false for production.
@buenosaires read this chapter:
@vincent15000 I meant don't forget to remind folks about security.
Edit:
I suggest not using .env in production, see martinbean answer here: https://laracasts.com/discuss/channels/laravel/security-question-for-env-file?page=1&replyId=859893
@jlrdw I talked about the .env file in the Laravel backend. Is it recommended to not use it ? Why ? I'm not sure to understand.
@vincent15000 .env is meant for development. It's just more secure to use the actual config files in production. But many people use it anyway that's up to you.
@jlrdw do you mean turning APP_DEBUG to false in the .env file before running npm run build?
@BuenosAires where ever you use that line, make it false for production. I do it in config/app
|--------------------------------------------------------------------------
|
| This value determines the "environment" your application is currently
| running in. This may determine how you prefer to configure various
| services the application utilizes. Set this in your ".env" file.
|
*/
'env' => env('APP_ENV', 'production'),
/*
|--------------------------------------------------------------------------
| Application Debug Mode
|--------------------------------------------------------------------------
|
| When your application is in debug mode, detailed error messages with
| stack traces will be shown on every error that occurs within your
| application. If disabled, a simple generic error page is shown.
|
*/
'debug' => (bool) env('APP_DEBUG', false),
I do not use .env in production.
@jlrdw Thank you so much for taking your time to answer my doubts. I have one last question that i would love if you could answer it: does my build when i put it on a server automatically link up with its database? What i mean is that, as long as i previously imported the migrations to the database, does the models correctly interact with it? No further work has to be done by me to make that link correctly function?
Im asking this questions because when im developing i have to literally put my database name, my username and password in the .env file to make the model interaction work, but it seems i dont have to do anything like that when deploying for production on a server.
@jlrdw Yes sure in production the debug mode has always to be false.
And yes that's right I use the .env file in production.
So you mean that database credentials and all other datas that are in the .env file should be better in the different appropriate configuration files ? That's ok for me.
Now I just need to understand why because the danger that the .env file is read is as high as the danger that the configuration files are read, no ? And the configuration files retrieve the credentials from the .env file.
@vincent15000 most servers support adding environment variables in other ways apart from files. For instance, on DigitalOcean you can set them via the dashboard, or if you have SSH access you can set them directly on the system.
It's a security risk to use them because of potentially misconfigured servers, where you cannot protect files and place everything in the root folder, which on shared hosts are usually all public. You don't wanna know how many sites I've browsed where the .env file was in a publicly accessible place, it's frightening how many developers overlook it.
@BuenosAires your code is pushed to production but you still need to import your data or run a migration on the server.
And that all depends on your particular server like digital ocean versus a shared hosting.
Usually a host will have how to articles I know digital ocean does.
What npm run {command} does, differs from project to project. Depending on your settings, what plugins you have installed, and what asset bundler you use.
For Laravel and Vite, the npm run dev command is used for development and NOT production. it starts the Vite development server on port :4173 which includes hot module replacement for instance. Not to be confused with your local web server that serves your Laravel application, whether that be XAMPP, Docker, or Valet, this is only for assets handled by Vite.
For production we run npm run build, that command generated versioned production assets for your project under the public/build folder. These assets are not normally tracked by Git since they're generally created on the production server or in a CI/CD pipeline. If you don't have that capability, like on shared-hosting for instance, you can remove the /public/build line in your .gitignore file to track the files.
What each command does is covered in Laravel's documentation under Running Vite, I'd spend a few minutes browsing the documentation to familiarise yourself with how Laravel and Vite work together. And as @jlrdw suggested, I'd also recommend reading up on the deployment part of the documentation.
And at no part does Vite generate a .env file for you. And asset files are not stored in the database, they're located under the public/build folder once built. If you're getting an error containing a line similar to failed to load manifest or connect http://127.0.0.1:4173/hot make sure the public/hot file is removed after you stop the Vite development server. That should also not be tracked by Git or uploaded to the production server.
Please or to participate in this conversation.