Add more options to the "action" advice

[ematipico]

At the moment, among the plenty advices that we have, there's the type action.

This advice would allow us to have a command (and flags) to fix the diagnostic.

My proposal is to also add the possibility to specify a partial configuration, in case the issue can be fixed via configuration. This would allow us to do a bulk update by looping through all the diagnostics, without the necessity to run multiple commands to fix the issue.

This would come in handy in case we have lot of issues related to invalid licenses.

[sebmck]

You can already specify the following advice action to update a config:

{
	type: "action";
	command: "config",
	args: ["set", "foo", "bar"]
};

What did you have in mind?

[ematipico]

In a real world example, where we could have dozens of invalid licenses, we would have dozens of relative diagnostics that would suggest to run dozens of config command.

This might be useful inside a LSP environment but I don't think it's a ideal inside a auto-config situation. We would need to run lot of times the config command. It seems expensive from my point of view.

I would end up doing something like (pseudo code):

for (const [advice] of diagnostics) {
  await req.query({
    command: advice.comamnd,
    commandArgs: advice.args
  })
}

While if we'd give a partial configuration, we could put them one single object and update the configuration only once:

const config = {};
for (const [advice] of diagnostics) {
   config = {
      ...config,
      ...advice.config
   }
}
await updateConfig(config)

[sebmck]

Ah right. A big design decision for how action is structured is there's enough information there for us to efficiently dispatch internal requests, but if diagnostics were opened up as a public API then it could be used there to call the Rome CLI or use the client API. A action-update-config diagnostic advice wouldn't make that very straight forward.

I wonder if there's a way we could implement batching. We could have some way of allowing a command to specify a custom method for ingesting multiple client requests at the same time. That way we would get the behaviour you describe, still have all the advantages of having it generic, all while not even having to change our existing API.