Future of drupal-composer/drupal-project compared to drupal/recommended-project

[petercossey]

Related to #535

What's the future of this project compared to drupal/recommended-project?

If this project is going to continue, what are the points of differences and the use-cases for developers to start new projects with drupal-composer/drupal-project compared to drupal/recommended-project ?

[webflo]

Hi,

i think this project has its purpose. Here are a few differences to the official template:

• Ships with drush and Drupal console
• Ships with dev dependencies (testing with phpunit)
• Drush config files for site-alias and PolicyCommands
• Configures config_sync_directory in settings.php to (config/sync)

[leymannx]

I also see great advantages in this project's ScriptHandler. Which I find an excellent starting point to include more advanced logic like for example executing other different commands to precompile assets as post install or post update commands.

[Coufu]

I tried drupal/recommended-project and ran into issues right away when trying to install Drupal modules via composer require drupal/foobar. Also it didn't come with a .gitignore, which doesn't sound like a big deal, but it just seems like an oversight. If they didn't include a common/starter .gitignore, what other basic things did they not include?

Gonna stick to drupal-composer/drupal-project for now since it hasn't let me down. I also like that it comes with drush, drupal console, and cweagans/composer-patches

[petercossey]

@webflo @leymannx @Coufu thanks for the info.

In summary:

drupal/recommended-project is a "bare-bones" composer template which developers can use as a starting point to build a project but which requires additional configuration for most projects.

drupal-composer/drupal-project is a "batteries included" composer template which gives developers a Composer setup that follows current conventions for development dependencies, configuration storage and testing (Drush, Drupal Console, .gitignore) for most Drupal projects.

Does that sound fair and accurate?

[simesy]

drupal/recommended-project will certainly evolve (I'm sure it will get a gitignore), but it might make sense to call it "canonical".

drupal-composer/drupal-project is "conveniently opinionated" without being biased towards any commercial solutions, it proactively sets good practices (that I try to proactively spread by using it in projects). This project effectively proved the standards that are flowing upstream.

So maybe
drupal/recommended-project = core
drupal-composer/drupal-project = contrib

[skyred]

I am sure when Drupal core team made the decision, they were considering to continue using this. Could someone please link to the Core discussion here?

[gagarine]

@skyred https://www.drupal.org/project/drupal/issues/2982680

[leymannx]

@greg-1-anderson dropped some thoughts on that issue on Drupal Answers.

• The Recommended and Legacy project templates are maintained by Drupal core. As a result, it only includes those components validated by the core maintainers to be very stable and needed by most Drupal users. The bar for this is very high, and the complexity of the component plays into the decision. For example, Drush is very stable and used by most Drupal users, but it is a fairly large and complex project, and therefore has not been added to a core project template. Use the Recommended project if you'd like your web root inside a "web" directory, or the Legacy project if you would like your web root at the project root.
• The drupal-composer/drupal-project template is maintained by the community. It contains more components that are likely to be useful to a wide range of users. If a bug or configuration problem is found with this project, then it must be reported and fixed through the community repository on GitHub.

[petercossey]

After reading the Core discussion linked above and some of the other issue threads on Github the difference between the two projects (at least for my own professional purposes) seems pretty clear.

From my perspective, the principles and opinions of drupal-composer/drupal-project template include:

• aiming for best practice for developers who want to use a Composer (i.e. modern PHP) workflow for managing custom Drupal/PHP projects. e.g.:
  • don't commit the vendor directory;
  • git and/or composer isn't necessarily a deployment strategy, it's an approach to manage a complex web of dependencies;
  • what gets deployed to a hosting environment is an artifact of the project and the composer ecosystem has great tools for scripting all those develop/build/deployment strategies;
  • developers are responsible for creating their dev/build/deployment strategies and the Composer ecosystem provides a great platform for creating those strategies using scripts, dev projects etc.

(Not suggesting the points above relevant to everyone but they're just the opinions I'm working with when I use this project. Might be different for others.)

Whereas for the core project, those principles seem to be more informed by stability and accommodating the many different use-cases and user groups of the project. It's also slower moving (which is a good thing IMO), because stability is key. It's also more of a core development issue right? What's the conservative, bare-bones, stable starting point for a composer template for just Drupal, without bundling a bunch of 3rd party dependencies and development opinions.

Is it fair to say that drupal-composer/drupal-project is a good starter kit for developers working on custom Drupal projects who want a "batteries-included" starting point for a custom Drupal project with all the Composer tooling + some code/project management opinions?

Is there something we can add to the README of this project that gives a useful comparison between the drupal-composer/drupal-project and drupal/recommended-project that gives new and existing Drupal developers the information to make an informed decision without creating the sense of a false competition between the two approaches?

I like what @greg-1-anderson has posted on Drupal Answers... I also like the practical items that @weitzman listed on #550

This template has a batteries-included approach such as built in support for .env files, drush+drupal-console

[greg-1-anderson]

c.f. #550 (comment)

[guix77]

I can see why Drupal wants to maintain https://github.com/drupal/recommended-project and https://github.com/drupal/legacy-project.

What I can't understand is why they are officially recommended by Drupal. They don't even have a README.

https://github.com/drupal-composer/drupal-project is light years ahead and should be officially recommended in my opinion.

[AlexSkrypnyk]

Just want to point out that in 5 years, since 2019, drupal/recommended-project has remained practically unchanged. This means that this project (and other projects like this) have their place in the ecosystem.

In addition, neither creation of the consumer project using drupal/recommended-project (composer crate-project drupal-composer/drupal-project) nor adding it as a dependency does provide a full set of ready-to-go production-grade project configuration, meaning that there will still be a need to customise the consumer project further, essentially replicating what drupal-composer/drupal-project does.

I'm going to close this issue as, based on the last 5 years, it does not seem like the future of this project depends on drupal/recommended-project's functionality.

In addition, some automations are still using this project, so it should continue to exist and be maintained to support newer Drupal versions.