Problem/Motivation
It is a long-standing issue with Package Manager (and its implementers, specifically Project Browser and Automatic Updates) that we don't really know precisely what Composer is going to do ahead of time, if asked to add or update or remove a package.
This is a large reason why we need to do sandboxing. Create the sandbox, do some Composer stuff in there, and compare it against the live site to be sure we're not about to do anything damaging.
Annoyingly, Composer has a --dry-run option for several of its subcommands (including install, update, require, and remove), but Package Manager can't really take advantage of that because its output is not machine-readable.
But if only we had some way to find out what Composer is going to do before it does it...we could feel much more confident about Package Manager making changes, regardless of whether or not those changes will be done directly on the live site (in
direct-write mode →
), or in a sandbox.
Proposed resolution
There's a way, but we need to create a new Composer plugin to do it.
Composer dispatches an event (\Composer\Installer\InstallerEvents::PRE_OPERATIONS_EXEC) before it actually does the install/update/remove operations it's got lined up. This event is dispatched regardless of whether the --dry-run flag is present.
Although it slightly touches on internal parts of Composer, this event gives us everything we need to determine what packages will be changed and how.
So what if we did this:
- Create a Composer plugin which listens to this event and uses it to generate a JSON file with the complete information about what is about to happen, and which packages will be affected, in which versions. This would be a normal core-maintained Composer plugin with its own subtree split, just like core-composer-scaffold or core-recipe-unpack.
- Add a validator to Package Manager which requires this plugin to be installed and enabled in your project. (As part of doing this, we would add the plugin to core's project templates.)
- Change Package Manager so that it always executes a dry-run of any
require operations, giving PreRequireEvent subscribers a "before" and "after" state to compare against, regardless of whether sandboxing is in use.
Remaining tasks
Decide whether we want to take this approach, or something similar...then do it. Probably this will take multiple issues.
User interface changes
None anticipated.
Introduced terminology
None anticipated.
API changes
There might be some changes in Package Manager, but this is TBD.
Data model changes
None.
Release notes snippet
TBD.