align "configure task" and "task quick open" with vs code

[elaihau]

• edit the right task.json when clicking "configure task" in multi-root
  workspace (fixed [tasks] unable to configure tasks when in a multi-root workspace #4919)

• in the current Theia, when users configure a detected task, the entire task config is written into tasks.json, which introduces redundancy.
  With this change, only properties that define the detected task, plus problemMatcher, are written into tasks.json. (fixed users shouldn't have the flexibility of customizing all properties of a detected task #5679)

• TaskConfigurations.taskCustomizations is a flat array, and the user can only customize one type of detected task in one way.
  With this change Theia supports having different ways of task customization in different root folders.

• allow users to override any task properties other than type, and those that are used to define the in its task definition.

• The detected tasks, once customized, should be displayed as configured tasks in the quick open. (fixed Configuring of a task #5747)

• The same task shouldn’t have more than one customization. Otherwise it would cause ambiguities and duplication in tasks.json (fixed "configure task" should not add duplications to task.json #5719)

Signed-off-by: Liang Huang [email protected]

[elaihau]

Configure tasks in different root folders of a multi root workspace:

Once a detected task is configured, it is displayed as a configured task:

The configured detected task cannot be configured for more than once:

Lastly, as the GIFs shown above, with this change, "configure task" does not write the entire task object into the tasks.json. It only writes the properties that are used to defined the task, and problemMatcher.

[lmcbout]

Code seems ok with minor comments
Can the 3 commits be squashed into one !
Not tested the runtime exec yet

[elaihau]

Code seems ok with minor comments
Can the 3 commits be squashed into one !
Not tested the runtime exec yet

Thank you for the review @lmcbout @vince-fugnitto !
I will also do more tests on my side.

[vince-fugnitto]

@elaihau I don't have any issues codewise :)
Do you mind sharing on how we can successfully test the PR (mainly how to get detected tasks)?

[RomanNikitenko]

I tested the changes locally using npm extension and can confirm that:

• task after configuring is displayed as configured
• no redundant fields are present after configuring a detected task
• it works well for a multi-root workspace
• user can configure a task only once

so, thank you @elaihau for the fix - well done!

I would like test the running a configuration from recently used section after configuring and so on.
Do you know some vs code extension which provides task configurations with args available for editing by user? I mean it's hard to reproduce the described case above for npm, because this one has only script and path fields. Maybe you know some extension with tasks which allow to edit command filed or args and can be good example for testing to check - is configured configuration is used for execution or detected one from recently used section.

thank you!

[elaihau]

Maybe you know some extension with tasks which allow to edit command filed or args and can be good example for testing to check - is configured configuration is used for execution or detected one from recently used section.

thank you!

@RomanNikitenko Thank you for testing, really appreciated !

from my understanding in vs code the command property can not be customized. And this patch does not support customizing the command either.

As per our discussion in #5679 (comment), I should add support to allow users to override all properties such as command. Please give me two days (sorry I am not working full time on this) and I will make a patch to this PR.

[elaihau]

@elaihau I don't have any issues codewise :)
Do you mind sharing on how we can successfully test the PR (mainly how to get detected tasks)?

We could install vs code extensions such as npm and grunt as plugins in theia (Jacques has a lot of experiences on that :)). the npm scripts and grunt tasks defined in your project would be detected by those extension and get displayed in the task quick open.

[elaihau]

@RomanNikitenko with the latest change in this patch you would be able to override any properties, except for type, and those that are used to define your detected task.

take npm tasks for example, from its task definition

      {
        "type": "npm",
        "required": [
          "script"
        ],
        "properties": {
          "script": {
            "type": "string",
            "description": "%taskdef.script%"
          },
          "path": {
            "type": "string",
            "description": "%taskdef.path%"
          }
        }
      }

we know script and path are used to define tasks, and therefore we could override any properties other than script, path, and type.

Please see this GIF for example

npm lintAAA executes eslint . on the first root folder of the workspace. with users overrridding command, args, and options, it runs ./task script from the other root folder.

Please let me know if this supports what you needed. Thank you !

[RomanNikitenko]

@elaihau
I'm going to test your changes today
Thank you very much!

[RomanNikitenko]

@elaihau
I tested again cases mentioned here after PR is updated, also tested this case. It works well for me!

For our assembly we need some adaptation, but looks like it's on our side, so @elaihau thank you for giving me time for testing and analyzing!

[elaihau]

Thank you for the review and testing @RomanNikitenko , really appreciated !