Drupal's extension discovery system uses a recursive file search to find all available modules. While doing so it requires a very Drupal specific project layout. At the moment this requires all the Drupal projects to use the composer/installers project as well as include specific configuration in their root composer.json. Additionally configuration of tools such as git, PHPUnit and PHPStan must be explicitly configured to ignore extensions not native to the project. In contrast, in other PHP projects those tools only need to ignore the vendor/ directory which contains all external code.
As of Composer 2.1 (specifically the composer-runtime-api), Composer now includes \Composer\InstalledVersions::getInstalledPackagesByType which can be used to get the locations of packages installed of a certain type.
Drupal modules already have their own type to support our current structure. This makes it easy to use this new method to introspect composer for the location of packages containing Drupal modules, rather than having to search specific areas of the filesystem.
There are a few tickets that are currently updating (or have already updated) the required composer version of Drupal 10 in such a way that we can start relying on the getInstalledPackagesByType method:
Update the extension system to use the new Composer method to request the locations of packages with modules in them, rather than relying on a specific folder structure on the filesystem.
This should be implementable as a backwards compatible change. From Drupal's perspective it's then also possible to discover extensions that live in the vendor/ folder. Additional work for core/contrib extensions may need to be performed for sites to work with extensions in the vendor/ folder since some modules may still rely on serving assets from a folder under the web root directly, rather than copying these from the module into the web root.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.