Part 1 | Part 2

In the first part of our two-part blog series on Drush 10, we covered the fascinating history of Drush and how it came to become one of the most successful projects in the Drupal ecosystem. After all, many of us know many of the most common Drush commands by heart, and it’s difficult to imagine a world without Drush when it comes to Drupal’s developer experience. Coming on the heels of Drupal 8.8, Drush 10 introduces a variety of new questions about the future of Drush, even as it extends Drush’s robustness many years into the future.

Your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) had the unique opportunity to discuss Drush’s past, present, and future with Drush maintainer Moshe Weitzman (Senior Technical Architect at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1), as part of the Tag1 Team Talks series at Tag1 Consulting, our biweekly webinar and podcast series. In the conclusion to this two-part blog series, we dig into what’s new in Drush 10, what you should consider if you’re making a choice between Drush and Drupal Console, and what the future for Drush might hold in store for Drupal’s first CLI.

What’s new in Drush 10

Drush 10 is the version of Drush optimized for use with Drupal 8.8. It embraces certain new configuration features available as part of the upcoming minor release of Drupal, including the Exclude and Transform APIs as well as config-split in core. Nevertheless, the maintainers emphasize that the focus of Drush 10 was never on new additive features; instead they endeavored to remove a decade’s worth of code from Drush and prepare it for many years to come.

To illustrate this fact, consider that Drush 9 was a combination of both old APIs from prior versions of Drush and all-new APIs that Drush’s maintainers implemented to modernize Drush’s commands. Therefore, while Drush 9 commands generally make use of the newly available APIs, if you call a site with Drush 9 installed from Drush 8, it will traverse all of the old APIs. This was a deliberate decision by Drush’s maintainers in order to allow users a year to upgrade their commands and to continue to interoperate with older versions. As a result of the removals of these older approaches, Drush 10 is extremely lean and extremely clean, and it interoperates with sites having Drush 9 but not those with earlier versions.

How should developers in the Drupal community adopt Drush 10? Moshe recommends that users upgrade at their earliest convenience through Composer, as Drush’s maintainers will be able to offer the best support to those on Drush 10.

Why Drush over Drupal Console?

One key question that surfaces frequently concerning Drupal’s command-line ecosystem is the distinction between Drush and a similar project, Drupal Console, and when to use one over the other. Though Drush and Drupal Console accomplish a similar set of tasks and share similar architectures because they both depend on Symfony Console, there are still quite a few salient differences that many developers will wish to take into account as they select a command-line interface to use with Drupal.

Commands, for instance, are one area where Drush and Drupal Console diverge. Command authors will find that commands are written quite differently. Drush leverages an annotated command layer on top of Symfony Console where developers employ annotations to write new commands. Drupal Console instead utilizes Symfony Console’s approach directly, with a few methods attached to each command. However, this is a minor consideration, as there is little to no difference in the CLI’s functionality, and it is merely a stylistic preference.

Drush and Drupal Console also differ significantly in their approaches to testing. Whereas Drupal Console performs unit testing, Drush prefers functional testing, with a full copy of both Drupal and Drush in their test suite. All Drush CLI commands are run on a real, fully functional Drupal site, whereas Drupal Console opts to leverage more mocking. There are admittedly many advantages to both approaches. But perhaps the most important distinction is of a less technical variety: Drupal Console has seen a bit less contribution activity as of late than Drush, which is an important factor to consider when choosing a CLI.

The future of Drush: Drush in core?

Though Moshe and Greg have committed themselves to maintaining and supporting Drush in the future, there are doubtlessly many questions about Drush’s roadmap that will influence decision-making around Drupal.

Drush’s inclusion in core has long been a key talking point with a variety of potential resolutions. Drupal already has two CLI commands in it unrelated to Drush, namely the site-install and quick-start commands, which are seldom used as they have limited coverage of key use cases. For instance, site-install only installs Drupal successfully on SQLite databases and lacks consideration for configuration. Drush’s maintainers are keen on considering a version of Drush in core, and an active discussion is ongoing.

Moreover, now that the starter template for Drupal projects is now deprecated in favor of core-recommended, there is an opportunity for Drush 10 to serve as a key dependency in those starter templates, initially as a suggested dependency and eventually as a required one. Some of the key commands that a hypothetical Drush in core would encompass include enabling and uninstalling modules as well as clearing caches and logging in as a user. In the not-too-distant future, a Drupal user could start a Drupal project and immediately have Drush and all its commands available from the very outset.

Conclusion

Drush 10 is an inflection point not only in the history of Drupal but in how Drupal developers interact with Drupal on a daily basis. Thanks to its leaner, faster state, Drush 10 marks a new era for remote interactions with Drupal. Because Drush 10 has tracked closely to the Drupal 8 development cycle, many of the core changes present in Drupal 8.8 are reflected in Drush 10, and the ongoing discussion surrounding the potential of Drush in core will doubtlessly continue apace.

For many of us in the Drupal community, Drush is more than a cherished tool; it is one of the primary entry points into Drupal development. With the help of your contributions, Drush can reach even greater heights. Moshe recommends that new contributors get started with improving Drush’s documentation and content concerning Drush, whether it comes in the form of blog posts or step-by-step tutorials that make learners’ experiences much better. The Drush maintainers are always happy to link to compelling content about Drush, to address bugs and issues in Drush’s issue queue, and to offer co-maintainership to prolific contributors.

While this was an exhaustive look at Drush 10, it by no means includes all of the insights we gathered from Moshe, and we at Tag1 Consulting encourage you to check out our recent Tag1 Team Talk about Drush 10 to learn even more about Drush’s past, present, and future.

Special thanks to Fabian Franz, Michael Meyers, and Moshe Weitzman for their feedback during the writing process.

Photo by Bill Oxford on Unsplash.com