/public/css and /public/js to be gitignored already on fresh laravel project

[giunashvili]

It's like every time I create a new project I seem to forget to gitignore those 2 build paths, and it almost always ends up git-conflicting in my projects.

So, I think that it will be better to be ignored those two paths by default.
Is there any reason why should you want not to gitignore them?

The only thing I can think of is when you don't opt for resources/css and mix.js and write directly in the public/css/[something].css which I think of as an antipattern.
So, what are your thoughts about it?

[realtebo]

Question: if you ignore (re)builded assets in public, how to do you handle the release?

I ask because we are using git pull for releasing on servers, so we need all of these files.
It's just a question. I am interested in other's work methods and flows

[giunashvili]

@lucasdcrk Can I ask why?

[lucasdcrk]

I don't have node installed on my production servers and I find this method safer as I am sure what I tested locally is what's going live.
Both ways are OK IMO but i don't think we should change the defaults as people may be used to do this.
Also this would be an issue for people that don't use Laravel webpack and just place minified libs in public/css and public/js (even I did this when I started using Laravel)

[giunashvili]

So you have node_modules on version controll too?

[lucasdcrk]

Nope, I don't need node_modules on my production servers as the assets were already built locally.

[giunashvili]

I just remembered when I was using that approach.
there was really messy git history. because if you include those builds in the same commit as functionality, build files are always gigantic changes and it was made hard for me to find something that I was searching for. also if you commit builds separately you get 2x commits and half your history is useless for you cuz you'll never wanna check them.

Also, if you're working with pull requests and reviewers those things become much more cumbersome...

[fabiomlferreira]

For me this is a bad option, in many products we generate the assets on development servers and commit it to be push to production server.
Production servers don't need to have node installed and don't need to run npm commands.

[henzeb]

you don't need to run anything on the destination server. you don't even have to install git on your production server. You simply build it on your development server and upload this to the production server. just take a look at something like Forge.

[mbabker]

Ironically, Forge and Envoyer aren't the best supporting examples here.

Forge essentially does a git pull and whatever extra commands you add in directly on your production server, and directly in the app's working space.

Envoyer works with a ZIP clone of your repo's files and has separate directories for each deployment, but all of the provisioning steps (i.e. composer install or if you don't commit your compiled assets your npm run build step) still happen on the production server (albeit with a much better end-to-end flow that prevents a broken deployment from going live).

[henzeb]

Whoops, yeah you are right ...

[Michael-Stokoe]

By the relatively small sample size in this discussion I'd say it's more common to build assets outside of the production environment, and then publish them that way.

Which is weird because I've always built assets for production on the production environment using npm run prod as part of my deploy scripts.

Different strokes for different folks, I guess.

It does seem like a pain to add them to gitignore for every project, but realistically, how often are you creating new laravel projects, and why don't you have a custom gitignore ready to paste in if this is the case?

Like this one for example:

https://gist.github.com/Michael-Stokoe/812dcc2257b6b62adfd49e8a7d06438c

[fabiomlferreira]

The better approach is you have your own starter kit, I never start a plain new project, I have a starter kit with some basic stuff and plugins that I will use in all projects. I always clone that repository and start from that, for example I already have in it a custom gitignore, a translation plugins, a package to handle roles, a table for settings, a media library package

[giunashvili]

I always kept distance from starter kits, cuz they really soon get stale, and you have to create it again. And it's not practical.

[fabiomlferreira]

Yes you need update it often. But if every time you start a new project you need to create everything from scratch it’s a lot more time consuming.

In our company we start a new project almost every month, the starter kit make us gain more than 5 days in every new project.

[realtebo]

I prefer to install git and commit compiled assets instead of deploy single files.....

I say this because we CANNOT have CI/CD because ... too difficult ? too lazy ? ... every other ideas is still valid

[giunashvili]

laziness is not an argument.

[BrekiTomasson]

While I have to admit that I, too, am guilty of the sin of compiling assets on development, pushing them to git, then pulling them to the production environment, my ideal situation would probably be:

• Assets built for development are not obfuscated, minimized, cleaned, etc. Basically, the css files should just be the final results with all the comments, spacing, line breaks and goodness still in there to make it easy to debug and troubleshoot.
• Assets built for production are obfuscated, minimized, all the comments removed, etc.

So, obviously, you need two different sets of css/js assets, but since you don't want to build on production, it could just as easily be done in a Github Action and then included in whatever is pulled.