Provide core CLI commands for the most common features of drush

#2242947: Integrate Symfony Console component to natively support command line operations → is still out there and postponed, but I def want to point out another which seems to have more energy on the follow-through at this point:

✨ CLI entry point in Drupal Core (Dex) Needs review

I think this issue is better off in the core queue, needs architecture more than product discussion.

Not sure what the best component for this is, but going with base system, since I'm guessing setting it to ajax was probably an unintended change of moving to from ideas to core ;)

I keep forgetting Drupal even provides commands. They aren't quite at the point the can replace any drush workflows for me though I guess.

Maybe we should start moving this in front of people more. The Drupal console isn't active these days so since it won't conflict could we start pushing core/scripts/drupal into vendor/bin/

Then maybe we could start looking at using a discovery mechanism of some sort for auto discovering commands instead of hard coding them.

Then we could encourage people could start tinkering with this, testing real world use cases, without hacking on core as directly?

I just looked into this yesterday. I had forgotten about the built-in commands, too. However, I use DDEV Drupal Contrib, and when I set up a contrib module dev environment, Drush isn't installed, unless the contrib module has it in its composer.json, which almost none do.

So I was trying to find a way to install Drupal from CLI, without Drush. It's not easy, and the built-in commands don't support arguments for all the options available in the UI, and you can't use MySQL instead of SQLite as far as I know.

@neclimdul, Mile23 linked to the most recent development on discovery.

@solideogloria, I was trying to work on that, but i haven't been able to write tests successfully for it in #2894476: Provide commands which are helpful for core development → .

@solideogloria you can install Drush into the project yourself.

One of DDEV Drupal Contrib's features is that it does all of its work without modifying the module's composer.json. If I want to install Drush into the project myself, I have to modify composer.json.

I demonstrate how to do this without changing composer.json in https://github.com/justafish/ddev-drupal-core-dev/pull/33 - that could be done anywhere. @joachim has more opinions about how to manage this problem. But it's not a very big lift to just install drush and then let git and composer.json forget that you did it.

I like that command. That would be a cool addition!

@rfay, indeed, @joachim will point out that https://github.com/joachim-n/drupal-core-development-project does it without making changes to core's composer.json. I've filed PRs on justafish/ddev-drupal-core-dev to make it work with that Composer project template.

I like the discovery option proposed in #47. In the issue linked there, there is also a proposal to expose core/scripts/drupal as vendor/bin/drupal. No one from Drupal Console has weighed in on any future development plans related to that issue yet.

I will also point out that Starshot ships with Drush pre-installed, which will be helpful for folks who start with that as a base, rather than Drupal core. For core development, though, I like #57.

Instead of adding Drush to core we would built another Drush to add it to core. This is not DRY.

Eventually people then pick this approach up in their contrib modules and now have to provide 2 commands for the same thing, one for Drush, one for NotDRY.

Looking the other way instead of getting Drush closer to core, also doesn't sound fair to all the people who develop and maintain Drush. They do this for Drupal.

The plan for Drush 14 looks promising, maybe it can finally happen?

• Drush 14 is slimmed and ready for adoption by Drupal core
• Drush 14 Planning #6096