-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to declare multiple drush.services.yml files in one composer.json #5297
Comments
The expectation is that you have a composer.json in each directory (migrate and update). Its OK if the composer.json has nothing in it except for the drush line. |
Ah thanks @weitzman! I'll give that a try and contribute some language back to the docs if it seems like it would be helpful to others. |
Confirmed that adding minimal Here is a PR that adds a bit of language to the docs to describe this: #5312 |
…dules that provide Drush commands. This resolves the following complaints from Drush: [info] farm_migrate should have an extra.drush.services section in its composer.json. See http://docs.drush.org/en/10.x/commands/#specifying-the-services-file. [info] farm_update should have an extra.drush.services section in its composer.json. See http://docs.drush.org/en/10.x/commands/#specifying-the-services-file. See drush-ops/drush#5297
Existing document
https://www.drush.org/latest/commands/#specifying-the-services-file
What are you attempting to do
In some cases, a single project with a single
composer.json
file may have multiple sub-modules, each providing their own Drush commands anddrush.services.yml
files. How should this be handled in the project's rootcomposer.json
file?Two scenarios where this happens:
Specifically, I am curious how to solve this for (2) in the farmOS distribution, where we have two different modules that provide Drush commands:
And here is the distro's
composer.json
: https://github.com/farmOS/farmOS/blob/2.x/composer.jsonIn what way is the existing documentation unclear or incomplete
It is unclear how to handle the above situation.
What should the documentation say instead?
TBD (and happy to open a PR once I understand!)
The text was updated successfully, but these errors were encountered: