Hello, this is a question that's hunting me for a couple of months, I have seen people update composer and npm packages on every new feature deploy of a Laravel project.
In my case I push to a Bitbucket repository and that pushes changes and features to the production server.
Do you think that would be a good idea to update composer and npm packages before each git push and do the same on the production server when deploying?
I really never finished to understand the idea of doing these updates. If you have some information on this use case please share it.
So when talking of the composer workflow, the approach would be to run composer update on local env and then when deploying to production run composer install? And repeat this flow on every deploy?
😵 I was updating packages in both local and prod environments.
The npm workflow would be to run npm update on local env and nothing on production?
So when talking of the composer workflow, the approach would be to run composer update on local env and then when deploying to production run composer install? And repeat this flow on every deploy?
Yes.
The npm workflow would be to run npm update on local env and nothing on production?
npm install and npm run production on production. Assuming you use mix.
I use mix yes. I think I don't explain correctly...
I wanted to know if I need to run something on the production server. The composer workflow is understood, run composer update on local machine and run composer install on the production server on every deploy.
The npm workflow using mix would be to run on local machine run npm watch on dev env and before pushing to prod server run npm prod. But nothing on the production server.
@charrua You update dependencies when you need to. This will record the exact versions installed in a lock file so that when you go to deploy your project, you can run composer install / npm install and know that the exact same versions you were working with locally will be installed on your server.
Running composer update may install an updated version of a dependency. So you should only do that (and commit the updated lock file) if you’re expecting a dependency to be updated to the latest version within the constraints you’ve specified. Usually this is OK if you’re just updating minor versions, which should contain bug fixes and non-breaking changes only.
Also, you shouldn’t include your vendor and node_module folders in your Git repository if you are.