Skip to content

Commit

Permalink
Update commands docs (#5249)
Browse files Browse the repository at this point in the history
  • Loading branch information
weitzman committed Sep 21, 2022
1 parent ea7bea8 commit c2567a8
Showing 1 changed file with 7 additions and 9 deletions.
16 changes: 7 additions & 9 deletions docs/commands.md
Expand Up @@ -4,7 +4,7 @@ Creating a new Drush command or porting a legacy command is easy. Follow the ste

1. Run `drush generate drush-command-file`.
2. Drush will prompt for the machine name of the module that should "own" the file.
1. (optional) Drush will also prompt for the path to a legacy command file to port. See [tips on porting commands to Drush 10](https://weitzman.github.io/blog/port-to-drush9)
1. (optional) Drush will also prompt for the path to a legacy command file to port. See [tips on porting commands to Drush 11](https://weitzman.github.io/blog/port-to-drush9)
1. The module selected must already exist and be enabled. Use `drush generate module-standard` to create a new module.
3. Drush will then report that it created a commandfile, a drush.services.yml file and a composer.json file. Edit those files as needed.
4. Use the classes for the core Drush commands at [/src/Drupal/Commands](https://github.com/drush-ops/drush/tree/11.x/src/Drupal/Commands) as inspiration and documentation.
Expand Down Expand Up @@ -61,7 +61,7 @@ A module's composer.json file stipulates the filename where the Drush services (
"extra": {
"drush": {
"services": {
"drush.services.yml": "^9"
"drush.services.yml": "^11"
}
}
}
Expand All @@ -71,17 +71,15 @@ If for some reason you need to load different services for different versions of
"extra": {
"drush": {
"services": {
"drush-9-99.services.yml": "^9.99",
"drush.services.yml": "^9"
"drush-11-99.services.yml": "^11.99",
"drush.services.yml": "^11"
}
}
}
```
In this example, the file `drush-9-99.services.yml` loads commandfile classes that require features only available in Drush 9.99 and later, and drush.services.yml loads an older commandfile implementation for earlier versions of Drush.
In this example, the file `drush-11-99.services.yml` loads commandfile classes that require features only available in Drush 11.99 and later, and drush.services.yml loads an older commandfile implementation for earlier versions of Drush.

It is also possible to use [version ranges](https://getcomposer.org/doc/articles/versions.md#version-range) to exactly specify which version of Drush the services file should be used with (e.g. `"drush.services.yml": ">=9 <9.99"`).

In Drush 9, the default services file, `drush.services.yml`, will be used in instances where there is no `services` section in the Drush extras of the project's composer.json file. In Drush 10, however, the services section must exist, and must name the services file to be used. If a future Drush extension is written such that it only works with Drush 10 and later, then its entry would read `"drush.services.yml": "^10"`, and Drush 9 would not load the extension's commands. It is all the same recommended that Drush 9 extensions explicitly declare their services file with an appropriate version constraint.
It is also possible to use [version ranges](https://getcomposer.org/doc/articles/versions.md#version-range) to exactly specify which version of Drush the services file should be used with (e.g. `"drush.services.yml": ">=11 <11.99"`).

## Altering Drush Command Info
Drush command info (annotations/attributes) can be altered from other modules. This is done by creating and registering 'command info alterers'. Alterers are class services that are able to intercept and manipulate an existing command annotation.
Expand Down Expand Up @@ -125,7 +123,7 @@ If a site-wide commandfile is added via a Composer package, then it may declare
```
Using `require` in place of `conflict` is not recommended.

A site-wide commandfile should have tests that run with each (major) version of Drush that is supported. You may model your test suite after the [example drush extension](https://github.com/drush-ops/example-drush-extension) project, which works on Drush ^8.2 and ^9.6.
A site-wide commandfile should have tests that run with each (major) version of Drush that is supported. You may model your test suite after the [example drush extension](https://github.com/drush-ops/example-drush-extension) project.

## Global Drush Commands

Expand Down

0 comments on commit c2567a8

Please sign in to comment.