allow to consume only subset of VS Code functionality

[akosyakov]

The plugin system has to depend on everything to provide support of VS Code APIs. It makes it very hard to customize Theia, since one cannot remove unnecessary packages as before, but had to use DI and rebind unnecessary contributions with stub implementations. This problems gets very acute if we do #7100. A particular case is #6645

I see several ways to resolve it:

• for the plugin extension convert runtime dependencies to Theia extensions to dev dependencies, use DI optional injection and typescript type import syntax to write guarded code, i.e.

import type { TerminalFrontendContribution, TerminalWidget } from '@theia/terminal';

@inject(Symbol.for('TerminalFrontendContribution') @optional
protected readonly terminalContribution: TerminalFrontendContribution | undefined;

get terminals(): TerminalWidget[] {
    if (this.terminalContribution) {
        return this.terminalContribution.all;
    }
    return [];
}

• make the plugin system mandator and pull to the core, but without any actual functionality, then each Theia extension should contribute relevant bits, so we kind of back to the arch we were before supporting the plugin system
• a hybrid of approaches above:
  • clean the plugin system from real functionality
  • add the plugin system as the dev dependency to each Theia extension to contribute relevant bits using DI optional injection and typescript type import syntax to write guarded code

Maybe someone has better ideas or see why or another approaches won't be feasible or harder to maintain.

[tsmaeder]

Maybe #8180 could play a role in this?

[paul-marechal]

I wrote #9309. Depending on an extension to get symbols and interfaces doesn't mean one wants it included in his application. But using optional bindings like Anton suggested would be useful in the situation where people exclude some extensions. TypeScript will see the types of the transitive extensions, Webpack will see their JS sources, but they won't be mounted using Inversify into your app. So current extensions could start being modified with optional bindings to support cases where the extensions they are relying on are not bound.

I think the PR I linked would play well with this issue and what Anton proposed?

In the PR's current state, if someone excludes an extension from their app they'll need to rebind the missing symbols themselves if something else is trying to use it. The amount of missing bindings will vary with the degree of coupling between the exts.