Cannot update to latest 11.3.x or 10.6.x core version due to impossible drupal/toolbar dependency

Updating title to reflect it's also an active issue for Drupal Core 10.6.x as well. And raising this to major since it's likely blocking the update to fix the latest CVE for anybody that cannot easily edit their project's composer.json file.

Saw in Slack that not backporting the replace fix to Core 11.3.x was intentional decision. Strange the infrastructure is adding the drupal/toolbar dependency on admin_toolbar's composer.json for both 10.6.x and 11.3.x. To unblock folks right away we could move the workaround into this module.

Make a new v4 release of admin_toolbar for Drupal 11.5 and 12. Then, set the v3 to be compatible with Drupal core less than 11.5 and include a "provide" or "replace" key workaround in the modules composer.json file.

@dydave, you can add a "provide" or "replace" key with the value of "drupal/toolbar: *" to this module's composer.json. It will work from anywhere in the dependency tree. I feel the "provide" key was more proper myself but either seem to technically work, and Core chose "replace".

Here's the explanation from Composer techdocs:

replace#
Map of packages that are replaced by this package. This allows you to fork a package, publish it under a different name with its own version numbers, while packages requiring the original package continue to work with your fork because it replaces the original package.

This is also useful for packages that contain sub-packages, for example the main symfony/symfony package contains all the Symfony Components which are also available as individual packages. If you require the main package it will automatically fulfill any requirement of one of the individual components, since it replaces them.

Caution is advised when using replace for the sub-package purpose explained above. You should then typically only replace using self.version as a version constraint, to make sure the main package only replaces the sub-packages of that exact version, and not any other version, which would be incorrect.

provide#
Map of packages that are provided by this package. This is mostly useful for implementations of common interfaces. A package could depend on some virtual package e.g. psr/log-implementation, any library that implements this logger interface would list it in provide. Implementors can then be found on Packagist.org.

Using provide with the name of an actual package rather than a virtual one implies that the code of that package is also shipped, in which case replace is generally a better choice. A common convention for packages providing an interface and relying on other packages to provide an implementation (for instance the PSR interfaces) is to use a -implementation suffix for the name of the virtual package corresponding to the interface package.

The issue is this is not compatible with Drupal 11.5 or 12, where you can actually install the new Toolbar contrib module. So it needs to be removed when your module installs with those core versions. I'll make an MR with the change using the "provide" key which reads like the correct option to me.

@dydave MR is ready for review with all green checks. Switching to a less than core constraint in the info yaml makes the "or" statements kind of awkward so I did the full range of compatible releases. Happy to change this if you'd like a different constraint strategy.

I went with the "provide" key but if you want the "replace" lmk and I'll swap it out.

Here's the logic regarding the version constraint if you want to settle on different numbers:

• Drupal 10.6.x and 11.3.x do NOT have the "replace" key workaround in core for "drupal/toolbar"
• Drupal 11.4.x has the workaround for "drupal/toolbar" in core itself
• Drupal 11.5.x and 12.x can install "drupal/toolbar" from contrib and the workaround for "drupal/toolbar" will break the install

@dydave That version strategy works great! I was wrong that toolbar was removed from Drupal Core 11.5 Beta. It's only deprecated, which is what I should have expected. I was thrown off assuming that the core infrastructure had a good cause to be injecting the contrib module dependency into your composer.json... but NOPE! It's just an obvious mistake.

Tested the MR on Drupal 11.5.0-beta1 (Standard profile). Admin Toolbar installs and works, with no JS or watchdog errors. Screenshots attached. Standard installs the core Navigation module, which hides the classic toolbar. I switched back to it with:

drush pmu navigation -y
drush en toolbar admin_toolbar admin_toolbar_tools -y
drush cr

@dydave Tested MR on Drupal 11.3.19 as well and it works! Screenshots attached. Hope that's enough testing? I don't have much need for Drupal 10 anymore but this fix should work there as well.