Best way to build and deploy FE assets for production with Vite?
I've just successfully migrated a project from laravel 8 & mix to laravel 9 & vite, and there seems to be a slight change in the "boilerplate", namely the "/public/build" folder is now added to .gitignore.
This means that, as opposed to with mix, you now "have" to build the assets on the live server, whereas before, you built the FE assets on your local machine and simply committed them to SCM. With Vite, I could simply remove the "/public/build" folder from .gitignore, but it got me wondering, if there are any donwnsides to building the assets on your local machine vs on the live server?
whereas before, you built the FE assets on your local machine and simply committed them to SCM
@roksprogar You’re not meant to commit compiled assets to your repository. They’re the results of compilation; they’re build artefacts. Just like you wouldn’t commit built binaries of a Go project or whatever. They also tend to be minified and therefore inflate your repository’s size and make diffs unwieldy. So yes, the public/build is Git-ignored and this is why.
You should also be building when deploying as you will most likely be using npm run dev in development, but should be running npm run build on your production server to build production-ready assets.
@martinbean that makes more sense, yes, even though that wasn't the case with laravel/mix out of the box, where both the uncompiled and compiled assets were built locally into the same file (for example, /public/css/app.css) and then committed to SCM for deployment, while cache-busting happened via a hash parameter in the link/script tag
where both the uncompiled and compiled assets were built locally into the same file (for example, /public/css/app.css)
You’d usually have your “source” file under the resources directory, and the compiled version would get saved under the public directory, as per the example above. Because if you built to the same file, it would just overwrite the original and you’d lose it.
@martinbean that's true, and I probably expressed myself incorrectly, but I meant that with mix, the assets built via the "npm run dev" command and the "npm run prod" always built the assets into the same file (even though the "source" files stayed intact and you could specify any directory you wanted, like in your example)...so while working in development, I was building unminified assets via the npm run dev/watch commands, but before pushing to SCM, I built the minified production assets locally and then committed the prod assets to SCM (because if I didn't do that, the "public/some/completely/random/directory/app.js" would contain unminified js)...maybe I misunderstood how mix is supposed to work, but I've been building the prod assets locally and then committing them to scm (to be deployed in production) for years...that being said, it does make more sense to do it on alive server with Vite (manually or via a CI/CD)
@hamidroohani Doesn’t matter if you’re using Docker, git pull-ing files, or FTP-ing them.
Build your assets on the server as part of your deployment process using rpm run build. I imagine you’re running other build commands (such as composer install) during deployment.
