Add drush/drush to Drupal Composer project templates

It looks like you have to uninstall Drush in order to update from Drupal 9 to Drupal 10: Can't update from Drupal 9 to Drupal 10 with Drush installed #5461.

My hunch is that this situation could have been avoided, if Drush was in core, due to tighter integration?

My assumption that Drush was that cause was wrong, which @moshe weitzman helped me realize. Following the steps on the upgrading Drupal 9 to Drupal 10 → documentation page, the process completes without a hitch.

This issue came up when discussing #3082230-50: [meta] Convert some tests to Build tests → and 📌 Add BuildTest for testing update using Drush Active .

Thats what I meant in the OP "The Drush maintainers have agreed to coordinate closely with the Drupal Release Management and Security teams." I also said it in the Drupalcon presentation linked from the OP. For now, this a good faith agreement from the Drush maintainers. I'm happy to agree to any more formal version once thats developed. IMO that formal version need not block this issue.

The thing is, I don't think that agreement is actually there from the release management and Security Team side (speaking as a member of both groups).

I would much prefer to add core commands for the most basic usecases of Drush (similar to the quick-start command), but leave Drush to handle advanced usecases, and not add a dependency to any core templates.

#50 raises the relevant point: Would we delay a core release for Drush? The answer of that is "No" from my perspective.

Maybe there are compromises we could consider, like adding it to the suggestions that Composer gives you when you install core?

I agree with #15 also.

We don't need to choose. We can add Drush to drupal/recommended-project AND keep adding commands to Drupal core. As core adds commands, the commands get removed from Drush. This improves out of the box experience and preserves core's autonomy to make the CLI experience it wants. Of course this requires some good faith co-operation, which I think we are all committed to.

I am weak -1 to this, for the reasons given in #46. When we (perhaps inadvertently) break Drush because of a change we want to make to Drupal core, whose responsibility is it to fix? If we start adding test coverage to ensure Drush runs against HEAD as in #50, what happens when an issue proposes a change that means that test starts failing? What happens if this is the case for a minor release?

To me the separation is a good thing and means that the Drush team can develop multiple majors concurrently and release them on their own schedule as they see fit. Adding Drush to a new project is already simple enough.

When we (perhaps inadvertently) break Drush because of a change we want to make to Drupal core, whose responsibility is it to fix?

1. One of the main raison d'etre of drupal/recommended is that versions of dependencies are pinned so nothing happens for the vast majority of sites when a new Drupal or Drush releases (unless the Drupal core devs want it to)
2. Drush is a downstream project from Drupal so if Drupal changes, then Drush has to adjust. This has been the case for a decade and will remain regardless of this proposal ... FWIW, Drush already runs its full test suite on every PR against Drupal's HEAD.
3. The good separation you mention is preserved when even when this proposal is accepted. Drush make new major versions as much as it wants - Drupal core adjusts drupal/recommended when it sees fit. And it can drop Drush dependency if Drush isn't keeping up.
4. For sure adding Drush isn't hard today. But discovering Drush can be hard, and it adds unneeded uncertainty for new users and documentation authors.

I agree 100% with #56 and #58.

Let’s get this move forward. Let’s add drush/drush to the drupal/recommended composer file.

For another issue discussion, though, which command will we register in the command-line?

$ drush for Drush
$ drupal for Drupal console (not maintained anymore)

Can we hijack $ drupal?

@longwave suggested a suggest entry instead, which I would also be fine with, especially as long as core doesn't include the minimum necessary commands.

@xmacinfo, it's not just a matter of "getting it moving forward". The IS states agreement with the release managers and Security Team, but no such agreement actually exists.

suggest supports only text and not version numbers. But at this point, a developer can install any version of Drush that support his Drupal installation and not a specific version.

But I feel we will quickly move to drupal-recommended as soon as we add code that needs Drush.

I would much prefer to add core commands for the most basic usecases of Drush (similar to the quick-start command), but leave Drush to handle advanced usecases, and not add a dependency to any core templates.

100% agree with this.

I would love to see the drupal cli script/executable gain more commands, for things like user and cache management. If in core we make a real effort to grow what drupal cli does, then I'd hope a contrib ecosystem would start to build up around it. With contrib modules providing their own commands. Maybe eventually what remains in Drush is just a contrib project that supplements drupal with more commands (just a thought).

One of the nice things from a dev/dev-ops perspective of other frameworks, like Django, which make heavy use of an out-of-the-box cli tool is it makes that experience a bit more enjoyable. So, by putting efforts into enhancing the drupal cli we would be enhancing the overall appeal of Drupal.

I'm not saying that Drush doesn't do that, Drush is excellent and I think we can all be thankful that it exists, but by not having most of the common commands in Core, we make that barrier to entry slightly higher for new people evaluating Drupal, they might not even know about Drush, they might just assume Drupal doesn't have very good cli tools and move on.

I'll admit this is starting to sound like I'm advocating for adding Drush to the recommended project template, but really I'm not. I'm advocating for bringing more of what Drush does really well into Core. In part because of what has already been said and the challenges that adding Drush to the template could introduce, but also because if we add Drush that kind of feels like we're saying that is "good enough", and we may never then make an effort to improve the drupal cli tool. At the very least, not having Drush in the template gives us all a bit of motivation to one day have those common commands in Core out-of-the-box.

I'm not sure which is best. But I just hope, for whatever attempt is made to include commands, that it doesn't become the next unmaintained Drupal console. Personally, I like that drush does it all, and I don't want to see half of the commands I want in some other utility, where I suddenly have to remember whether it's drush user:login or drupal user:login.

I don't want to see half of the commands I want in some other utility, where I suddenly have to remember whether it's drush user:login or drupal user:login.

I could not agree more. Drush is fantastic and we should continue to leverage that in the best way possible, which I believe is the motivation behind this issue. Whatever the outcome, I hope we continue to leverage and support the great work that the Drush maintainers do for this community.

Yeah, rebuilding stuff that already exists in Drush and then needing to maintain this rebuilt stuff doesn't sound DRY to me. Instead we should unify efforts to add Drush closer to the Drupal ecosystem.

Just for some context, there is already an existing "Drupal CLI" included with Drupal Core, you can find it at core/scripts/drupal, it's based on Symfony Console, which is what Drush is also based on, so the look and feel of it (colors) as well as the way commands work is pretty much the same as Drush. Adding more commands to it would be quite straightforward, it currently includes commands such as generate-theme and quick-start → . I believe contrib could also add their own commands.

Until a decision is made, is ✨ Link drush to vendor/bin/drush Active possible?