If a module installs additional dependencies, they should show up as installed right away

This one really had me stumped for a couple of days because there is no way for activators to know which source exposed the project they're working with, and more importantly, there is no way to know which source(s) expose the dependencies of a particular project. That's a good thing -- activators should not care about sources. But, since source IDs are used to identify projects sent to the frontend, this throws up a conundrum.

But I thought of a way to do it.

We should introduce a new AJAX command: RefreshProjectCommand. It takes two arguments: an array of criteria used to match a project already sent to the frontend, and an array of properties to update on that project. For example, let's imagine we install Pathauto (using ModuleActivator), which implicitly installs Token as well since that is a dependency. The activator could send something like this to the frontend:

new RefreshProjectCommand(
// Criteria by which to find the project.
[
  'project_machine_name' => 'token',
  'type' => 'module',
],
// Properties to update.
['status' => 'active']);

This would be pretty clean. The activators could continue to do what they do, which is...send AJAX commands. And the frontend would have a dedicated AJAX callback that knows how to deal with this.

Earlier all projects were re-rendered on installing project. Adding related issue 🐛 [Svelte] Remove the $updated key Active

#3 gives me an idea: we could add a new AJAX command that forces all visible instances of Project Browser to reload their data, using the previously known set of query parameters.

Activators which know that dependencies were enabled -- and we could add a trait for activators to easily figure this out -- could return this command, and that would get everything that was installed, to show up as installed.

It's a bit brute force, but I'm not sure there's a cleaner way to do this. I've been puzzling over this one for days and the architecture just don't allow it to be done using RefreshProjectsCommand.

Assigning to myself to see if this can work at all.

Discussed this with @chrisfromredfin in Slack and what we decided is that the smartest way to do this is for the frontend to explicitly request a refresh of all visible projects, since it (and only it) knows what projects are visible to the user.

So I think what we'll need to do here is add a new route -- the PATCH verb is probably the correct one for it -- which accepts a list of project IDs and returns an AJAX response with a RefreshProjects command for those projects.

We'll need to change the current activation route so it stops returning a RefreshProjects command by default, and instead, the frontend will make this new request when it finishes activating project(s) and running the AJAX commands the activators returned.

This means the frontend will be in charge of initiating a refresh, but I think that makes sense.

The PHP and JavaScript side of this wasn't hard, but this will need an explicit test.

Writing a test was surprisingly quick!

merged to 2.1.x

backport complete