Problem/Motivation
First of all, let me say this is not MVP for Package Manager.
There are a couple of places in Package Manager where we need to load file mappings used by the Drupal scaffold plugin. The design of the plugin allows these to be heavily overridden, using the following flow:
- The initial file mapping comes from drupal/core (see the
extra.drupal-scaffold.file-mapping section of its composer.json).
- Then, the
extra.drupal-scaffold.allowed-packages list, if it exists in the root composer.json, is consulted. In the listed order, any file mappings from those packages' composer.json files are applied.
- Finally, the root composer.json's
extra.drupal-scaffold.file-mapping section, if it exists, is merged in. This is how the root composer.json ends up having the final say about what will be scaffolded, and where, and how.
Right now, we are not at all accounting for this chain of overrides when we're trying to figure out what files will be scaffolded, and where. We simply read what drupal/core is defining, and run with that. But, given what we've just learned above, that's not at all guaranteed to be accurate.
Proposed resolution
We need some way to figure out what the actual file mappings at runtime will be, via the Composer inspector service.
We can't try to invoke the plugin directly at the API level; because it's a Composer plugin, its code won't be available to Drupal's autoloader. 👎
We don't want to try and compute it ourselves -- that would be duplicating quite a bit of internal logic from the scaffold plugin. 👎
What I think should happen is that core should add a new command to the scaffold plugin which computes the runtime file mapping, and outputs it as JSON. Then, the Composer inspector should call that command and parse the output to deliver the final, reliable file mapping.
