[Feature Request]: Support deployment/infrastructure-related `composer.json` file

[tyrann0us]

Is your feature request related to a problem?

In projects with a separation of concern between the infrastructure/deployment level and the application level, we use to have two composer.json files. The usual one in the root level and a different one in a deployment/ folder. The latter is meant specifically for packages that provide logic for certain tasks during deployments.

WP Translation Downloader is required in ./composer.json. But strictly speaking, it is a package not needed on application but on the infrastructure level. So it would make sense to move it to deployment/composer.json.

However, this currently does not work because it needs the packages it should download translations from to be listed in the "require" property of the composer.json file it is part of. This does not apply when used in deployment/.

Describe the desired solution

It would be great to have a WP Translation Downloader option for setting a "parent" or "main" composer.json. From there, it would read the "require" property.

This could either be a boolean setting like "search in the parent directory for a composer.json file" or a setting with composer.json path as the value.

Describe the alternatives that you have considered

Do nothing; keep WP Translation Downloader in main composer.json.

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[gmazzap]

I'm sorry, but I don't think a general-purpose Composer plugin should support anything like that.

Having separate composer.json for packages needed only on deployment is not anywhere a standard practice. It looks like a very custom and very arbitrary thing to do, and not even sure I understood what the purpose is.

(IMO that is not even "separation of concerns", as this issue proves that concerns are very coupled, but just a "separation of files")

That said, anyone is free to organize their code as they prefer, but I don't think it is a good idea to add complexity to a general-purpose package for the benefit of non-standard solutions. Being non-standard, any team could come here asking to support a different solution they are using, and if we would say "yes" to all of them, it would soon become an extreme mess.

If I understood correctly, but not sure I do, you could use the "composer merge plugin" to merge the root composer.json with deployment-specific packages that would be listed in the require section of deployment/composer.json. That should probably work in allowing your solution to coexist with this plugin. However, it won't require any change in this repo and, still not being a standard practice, it would at least be a "widely used" solution, considering the merge plugin has been downloaded more than 10 million times so far (only counting public usage). Being "widely used" it could make sense to ensure this repo supports it, even if I think it should already.