Merge conflicts with public files

@Pixelairport Building assets is a CI step. So yes, the generated assets should be Git-ignored, otherwise you’re just going to be constantly fighting conflicts.

In my applications, I have public/css/.gitignore and public/js/.gitignore files with the following content:

*
!.gitignore

That ignores all contents of those directories, expect for the .gitignore file itself.

When I deploy, I then run npm run production to build the assets for that deployment.

This means that only the sources are in your repository. Developers can run npm run dev or npm run watch on their machines, and servers run npm run production to build the assets for production (so minify, create source maps, etc) when deploying.

As @sergiu17 mentioned, you probably want to Git-ignore the public/mix-manifest.json file as well, as this can result in unnecessary diffs if the order of the files change, or if you use versioning resulting in the cache-busting query string constantly changing.

So, your next steps should be:

git rm -f --cached public/css/*.css
git rm -f --cached public/js/*.js
git rm -f --cached public/mix-manifest.json
echo "*\n.gitignore" >> "public/css/.gitignore"
cp public/css/.gitignore public/js/.gitignore
git add public
git commit -m "Stop tracking compiled assets"

This will remove the compiled CSS and JavaScript files from your Git index (but not your computer), and any future changes to these files will no longer be tracked by Git or pushed to your remote repository.

@Pixelairport yes, and you can automate that using a deploy service.

@martinbean Sorry, i thougth the question is solved, but I have a last question and hope this is seen by someone because this is marked as "best answer" (solved).

When you do npm run production on your server you also need all dependencies a dependencies and not DevDependencies or is that wrong? So you load all npm packages, even if they only be needed für publishing on your live server? I thought than the whole workaround makes no sense. I thought devDependencies is to be more secure and have less packages on live production? But maybe Im wrong and it is ok to do it this way?

@Pixelairport Packages should be listed in devDependencies if they’re only needed to build CSS and JavaScript. Once you’ve built your CSS and JavaScript, you could trash your node_modules folder. Laravel is a PHP framework. It doesn’t need NPM modules to function.

@martinbean Thx. Yes normally i put all in devDependencies to avoid to have these packages on live. You wrote "When I deploy, I then run npm run production to build the assets for that deployment.". That is why I try to understand how to do this on production. But now I think I understand that CI thing. I just started to use Actions at Github... Is it this what you mean with CI step? That I build it, while I run tests and other actions? Create the files while I deploy? We also have forge... I still never used it, but will start the next days with it. Maybe there are also options to do it. Sorry, that I ask again, but I want to be sure to understand and make it right in the future. Thx for your help.