Closed Drecomm closed 9 years ago
what speaks against the already existing way here?
The reason is, if modules would be able to define this, how would the project be able to overwrite them? Reason is, the deciding logic should always be in the project composer.json, never in the composer.json of a package. And decision for the deploy strategy is an big decision, and depending on the used installer or its version, the deploy method may or may not be availabil
There is nothing against the existing way. I would still have the project composer be leading in deciding how a module should be deployed.
The advantage is:
About the deployment method not being available, which is true for the project as the package composer, i would suggest if the deployment method is not available, the configuration is ignored.
I decide with the following reasons against this Feature:
I would like to configure the deploy strategy for some packages in the package itself. we use different deploy-strategies per package, almost in every project the same way.
would this be sufficient by itself, or should there be an extra configuration options, to specify that the packages configuration is used?
for example: the root composer.json contains:
one of the included packages contains: