Should compiled css be in version control or compiled on the server after every deploy?
I've always been storing it in version control, but starting to think it might be nice to have it compiled on the server. My thought is that commits would be less bloated, and I wouldn't have to remember to run gulp --production before each deploy.
Personally, I do put my compiled assets within version control. This is mainly because I host my servers on GoDaddy, and I can't get npm to run, which means that I can't use Laravel Elixir. Therefore, the server can only get the latest assets through version control.
However, if I could use npm on the server, then I wouldn't place these files within version control. I would just add gulp to my pull macro (Which does git pull, composer install, artisan migrate, and a few other things).
Usually if it's not something I would edit directly I probably won't include it in vc so that would include things like the composer.lock, compiled css/js, cache files etc.. Like tylernathanreed said it can depend on your hosting though e.g. on some of the lower memory VPS services you might need to commit your lock file to avoid memory issues generating it on the server.
I don't completely trust NPM or even gulp. I'd rather have it running locally and failing locally, instead of failing on the server and stuffing up a production deploy.
That prejudice aside, I can see that it would theoretically be cleaner to keep your build process server-side and your commits pure.
I prefer to keep as less code as possible in the VCS.
Everything you can compile/minify/something-fy based onto code you have in the VCS should be avoided. This way you keep everything cleaner and lighter.
When I have to publish to an hosting where I can't compile the assets after the checkout I create a gulp build tasks that compiles everything, clean them up and put all into a dist directory, then I update that directory. I prefer another deploy-specific repository with the compiled assets then keeping them into mine.
@Swaz In larger systems, you never overwrite existing production with a new build. So a new production is built and staged. That being said I have stored 'production images' in VC. But again how much is stored in place and which parts are 'built' by deploy scripts is always a preference. I try to go by 'lose no information', time travel to the past has always been a savior when "I know exactly what I am doing...".
I commit compiled files to VC, but don't have a huge opinion on whether that's a good practice or not. Just seems easier than risking doing it on a production server.
Just seems easier than risking doing it on a production server.
Yes, especially when you're normally only looking at a few tiny files.
You can make the same argument for including your vendor folder in VC, rather than running composer install on production. It's certainly "safer". But then you get thousands of cruft files in VC, so the trade-off is a bit different.
Also I feel less worried about running composer in production than gulp/npm. Maybe that's just prejudice.
