CODEWITHSUNDEEP
gitcomposer-php
praxus
praxus

Reputation: 508

Developing with different versions of dependencies

We are developing a PHP application and multiple module dependencies for it. In development we would like to use dev branches and in production tagged versions.
Problem is that some of those modules depend on each other.

What is the best practice to handle the workflow here?

Because if in the main app we require dev versions everyone has to remember to change it before merging to master.
One solution would be to use a separate composer.json file to developing but I think that wouldn't work with dependencies of dependencies.

To illustrate:

Main app composer.json in develop:

"module_1": "dev-develop",
"module_2": "dev-develop",

In "module_1" composer.json:

"module_3": "dev-develop"

In production main composer.json:

"module_1": "^1.0.0",
"module_2": "^1.0.0",

In "module_1" composer.json:

"module_3": "^1.0.0"

Upvotes: 0

Views: 194

Answers (2)

sleske
sleske

Reputation: 83587

I'm going to challenge the premise and say:

Don't do this.

Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.

Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.

That said, if you absolutely must have different dependencies during development:

Because if in the main app we require dev versions everyone has to remember to change it before merging to master.

This seems to indicate you develop features on branches, then merge to master. If that is the case, then the cleanest solution would be to change to production versions before the merge.

The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:

  • switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
  • re-test everything to make sure the switch did not break everything
  • merge (no merge conflicts in composer.json because it's the same on master)

Upvotes: 0

Micha Wiedenmann
Micha Wiedenmann

Reputation: 20843

One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.

Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:

I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?

The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".

Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.

Upvotes: 2

Related Questions