notify clients of TaskDefinitionRegistry on change

[elaihau]

• In current theia, task definitions from plugins are registered after the initialization of the task extension, causing task-loading, which counts on the existence of task definitions, not to function correctly. With changes in this pull request, events are emitted so that the clients of TaskDefinitionRegistry are notified and therefore have the flexibility to re-organize the loaded tasks.

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

How to test

1. Have a detected task prepared.

• What I did in this step is having npm extension installed in Theia, and adding at least one npm script, so that the project has a few detected npm tasks. Reload Theia frontend (example-browser).

2. Customize one detected task by adding an object in tasks.json, e.g.,

        {
            "type": "npm",
            "script": "lint",
            "problemMatcher": [
                "$eslint-stylish"
            ]
        }

3. Run the customized task.

What happened: the problem matcher, although defined in tasks.json, does not parse the task output, and therefore warnings and errors of the task did not show up in the problems view

What should happen: warnings and errors of the task, if any, should be displayed as markers in the problems view

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

[elaihau]

Without this change, #5877 and #5024 are broken by recent changes in theia

[akosyakov]

Design-wise it looks good, someone has to verify the behaviour. cc @theia-ide/task-extension

[elaihau]

@vince-fugnitto @marechal-p this change is ready for review and test. could you please take a look when you get the chance? THank you !

[vince-fugnitto]

@elaihau

I noticed something a little odd while testing, when executing the command Run Task... I only see one configured task, while if I open my tasks.json I see two:

Perhaps I am doing something wrong, I didn't quite understand how to properly test the PR.

[elaihau]

Hmmm, let me try the same. Probably there is a bug here. Thank you Vincent.

[elaihau]

@vince-fugnitto you tested it in the right way :)
it was a problem in the logic of filtering out duplicates. I fixed it and refactored the code.

[vince-fugnitto]

@elaihau do you mind sharing your example project in which you had the npm lint and problem marker defined?

[elaihau]

@vince-fugnitto yes https://send.firefox.com/download/f6550506fa184dea/#53ypwivg9tNAKUVfa6DHiA

the link is good for 5 downloads today

[vince-fugnitto]

@vince-fugnitto yes https://send.firefox.com/download/f6550506fa184dea/#53ypwivg9tNAKUVfa6DHiA

the link is good for 5 downloads today

Thank you! I'll test it shortly :)

[vince-fugnitto]

I tested using the example workspace you provided.

In my tasks.json I have the following task with the $eslint-stylish problemMatcher:

{
    "tasks": [
        {
            "type": "npm",
            "script": "lintAAA",
            "problemMatcher": [
                "$eslint-stylish"
            ]
        }
    ]
}

After running the task I can see the markers being populated in the problems-view:

[elaihau]

Thank you Vincent!