Try to reduce unused composer dependencies

This is already the plan, happy to have it documented here but not sure that we need anything further?

@pameela do you mean this:

There might be an interim step where Drupal CMS hard-codes specific recipes (and site templates when it gets there) that can be installed, but then rather than having them locally, they're composer required - so come from Drupal.org but without the browsing being in place?

If so that sounds good, but is there an implementation issue for that then? When I asked @phenaproxima he suggested opening an issue.

Yes exactly, we plan to specify the recipes we want to expose, but will need to do this in a way that it can be updated so not sure exactly how yet. Because hardcoding fully where it's static post-install is also not really acceptable.

We are also not sure what the actual recommended recipes will be. So since we don't know the recipes and don't know the mechanism, we don't have an issue but I guess we can create a placeholder that is postponed.

Do we still need this? Drupal CMS 1.2.0 uses recipe unpacking by default, so site owners are free to prune unnecessary dependencies as desired. I think that pretty much obviates this issue...?

site owners are free to prune unnecessary dependencies as desired.

How do site owners prune those dependencies?

composer remove such-and-such. There's no UI for pruning Composer dependencies, although surely one could be created with Package Manager as its base.

When I'm building Drupal sites, I composer require the dependencies I need then install them. Sometimes a dependency isn't needed any more, so I need to uninstall it, and then later composer remove it (because you have to deploy the uninstall before you can remove the code), this doesn't happen that often but it does occasionally.

Modules and their packages on composer don't necessarily match, so it's a fairly laborious process to audit a site for unused composer dependencies overall as opposed to requiring and removing as you go along.

When you update to a new major version of core, it's quite likely that some modules won't be compatible with that new Drupal version. Even if all the modules that Drupal CMS ships with are compatible with Drupal 12 or 13, this might not be the case for modules it shipped with in February 2025. In these cases, if a module isn't installed, composer remove is the easiest way to make your site compatible - but you have to know that it's not used and how to remove it.

This is going to be even worse for someone that's not familiar with composer on the command line or the nuances of composer requirements vs. installed modules, and it's exacerbated if sites start out with a large number of unused dependencies that were never installed in the first place.