Provide API to filter unwanted contributions

[tortmayr]

What it does

Adds the ContributionFilterRegistry which can be used to filter contributions of Theia extensions before they are bound.

This mechanism can be used by application developers to specifically filter individual contributions from Theia extensions they have no control over, i.e. core or 3rd party extensions.

Resolves #9069

Contributed on behalf of STMicroelectronics
Signed-off-by: Tobias Ortmayr tortmayr@eclipsesource.com

How to test

• You can take a look at the included test case, or
• Contribute a ContributionFilter in an example Theia application

Review checklist

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

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

Thanks for the contribution! Since this is going to be something core to Theia, I wanted to properly review it. Unfortunately I found enough things that bothered that I created a branch with most changes I'd be more comfortable with, see: eclipsesource/theia@filter-api...eclipse-theia:mp/filter-api-2

My issues mostly revolve around:

1. Class hierarchies too deep for not much value. Take the following:

   @injectable()
   export class SampleFilteredCommandContributionFilter extends NameBasedContributionFilter {
       contributions = [CommandContribution];
       doTest(toTest: string): boolean {
           return equals(toTest, false, 'SampleFilteredCommandContribution');
       }
   }

   It takes 3 abstract classes just not to write:

           return equals(toTest.constructor.name, false, 'SampleFilteredCommandContribution');

   It also seems to me that filters won't really be extended in such a way that we'll need crazy extensibility. Correct me if I am wrong.

2. Some of the logic can be rewritten more concisely.

3. Some styling issues. It most likely means that our linting rules are not good enough?

If you agree with the changes I proposed on the mp/filter-api-2 branch, feel free to squash them into your commit, populating the Co-Authored-By: Paul ... line for IP stuff. The commit I made already contains fixes for most of what I reported in my review.

[tortmayr]

Thanks @marechal-p for your in-depth review and the proposed changes.I squashed your changes and added the Co-Authored-By: line to the commit message. I believe all mentioned issues should be resolved now.

[tsmaeder]

This is a valuable contribution, but I think it would benefit from being done in a more functional style.

[tortmayr]

@paul-marechal I have squashed your proposal for a more functional filtering approach and rebased the PR onto the latest master.

[marcdumais-work]

@tortmayr just so you know, Paul is OOO this week, so it could take a few business days for a response, from him.

[tortmayr]

Thanks for the re-review @paul-marechal. I removed the string-utils.ts file and rebased onto the current master

[tsmaeder]

I like the general shape of this PR a lot now. I have a couple of questions I feel need answers though, hence a "Request changes".

[tsmaeder]

@tortmayr @paul-marechal so how are we going to proceed here?

[paul-marechal]

Waiting for @tortmayr to address the unaddressed comments?

[tortmayr]

@paul-marechal I have rebased the PR and addressed the open comments.

[JonasHelming]

@tsmaeder @paul-marechal : Are you good with this PR now?

[tsmaeder]

Looks good to me now.

[paul-marechal]

LGTM too, thanks!