I've developed a composer package that's included into many Github repo Laravel projects. It's set to a specific version, but even if I make it slightly looser and set the patch version to be a asterisk for the patch version I still need to run a composer update in the project that requires the package so that when running composer install on a server it installs the correct version.

The issue I'm facing is that when I release a new package version, I've got to run composer update locally, say 15 times each for 15 projects, then commit all 15, and open pull requests for all 15 etc making the process incredibly slow.

Is there a better way to handle composer update, maybe I need to develop a little CLI application to communicate with the Github api to open PRs and merge them?

CodePudding user response：

What you are describing is exactly what's expected and intended to happen. Full projects with commited lock-files are supposed to install the locked version unless updated.

You could use something like this composer update action to run regularly and create commits when necessary, or work with the GitHub provided Dependabot.

But if this is not coupled with a robust test suite and finely tuned version constraints, you could end up breaking already working projects because some randome dependency introduced an unexpected change in behavior.