CICD dependencies in composer.json

[lullabot]

CICD dependencies in composer.json

[juampynr]

We have seen cases where we may want to change the mink extension or the composer patches version. Having them in the Dockerfile makes it harder to test changing them.

I think that it is better to have these libraries getting installed as dev dependencies with the installer so they can be tweaked if needed and tested on pull requests.

Thoughts, @deviantintegral, @q0rban?

[deviantintegral]

Yeah, we actually used to do everything in the dockerfile back in an earlier, internal revision, and it made per-project configuration much harder. Also, it means that running tests outside of the docker containers is harder, because you don't know what dependencies you need.

Did you see this line in the Dockerfile for drupal_tests? It helps speed up builds by preseeding the Composer cache with the likely-shared dependencies, while still allowing composer.json to control the final dependencies. - Of course you did, it's what you linked to 🤦‍♂️

[dakkusingh]

@juampynr & @deviantintegral thank you again for your thoughts. I am getting to learn the inner workings :)

I think in the case of drupal8ci it perhaps makes sense to have the dependencies in the project composer.json. As this keep all project dependencies in the same scope.

@deviantintegral for drupal_tests, I am am not sure if we should have a module specific composer.json with its own (module level) dependencies. I could be wrong.

Say I am testing a project which requires a module (and module also has its composer dependencies), and these module level dependencies are either different from other modules or from the project. How does composer handle this mishmash of module and project level dependencies?

[deviantintegral]

Module level dependencies are pretty important - for example, we had a private module that ran into a Behat bug. We could work around it by pinning a specific version in it's composer.json, not affecting other modules.

Conflicting dependencies is not a real issue for dev dependencies, since they are only ever installed for one module at a time. For normal module-level dependencies, that's already an issue and one developers have to deal with. For example, if one module requires drupal/features: ^2.8, and another requires drupal/features: ^3.0, composer will throw an error on composer update and the site builder will have to decide what to do.

[dakkusingh]

@deviantintegral thanks again :)
I think it makes total sense when you have multiple use cases, just I hadnt encountered that issue yet