Improve Theia extension inter-dependencies

[paul-marechal]

Current State

Theia extensions currently depend on each other as hard dependencies. This means that when you install something like @theia/plugin-ext@1.17.2 your package manager will pull all of its dependencies with the same exact version.

We had to depend on exact versions when publishing to avoid some pain when Theia extension consumers, because having different ranges and whatnot led to duplicate installations of the same Theia packages.

But this starts to cause issues when trying to use third-party extensions that might not be updated as often, and then including those in your applications can lead to duplicated Theia core packages.

The whole issue revolves around defining inter-Theia extension dependencies as regular dependencies. Doing so means package managers make no guaranty that a package will only be installed once.

Peer Dependencies

Conceptually Theia extensions are build-time plugins that must be installed only once with a specific version, and they rely on other extensions to be installed alongside them. We even mount them together to create one big Inversify container.

A better way of expressing this relationship would be to use peer dependencies to link Theia extensions together.

Pros: (a) Package managers should not try to pull different versions of the same Theia package. (b) Ranges can be larger again, what's important is to target a minimal version. (c) The larger ranges mean that it will be easier to consume third party Theia extensions.

Cons: (d) Package managers will most likely not pull anything anymore. (e) Dependencies on Theia extensions all must be explicitly declared in the application's package.

The biggest reason I bring this issue up again is because of (c): Maintaining and consuming third-party extensions is a bit hellish.

Fortunately (d) and (e) can be fixed by adding the logic in @theia/cli to properly update/check an application's package so that everything is in working order (e.g. add/ignore missing extensions, ensure versions match, etc.)

Proposal

• Rewrite Theia extensions dependencies to work with peer dependencies (only for Theia extension packages).
• Use broader ranges for those peer-dependencies (making it easier to consume extensions not updated as often as core).
• Make @theia/cli ensure applications are still built correctly.

[tsmaeder]

Good idea, however, I'm not sure we need to be more lenient with the peer dependencies among theia packages: as I understand it, we always update all version numbers in parallel: if third-party packages depend on different version of theia, their dependency requirements are either compatible or not compatible: if they are not, I would consider that an error. It's up to third-party extensions to be lenient, not core Theia.

[paul-marechal]

I think as long as we use a range like ^1.X.Y where X/Y are the current minor/patch version it should be fine? Like you said we will move the lower bound up with each release of core extensions.

But the idea would be for third-party extensions to target something like ^1.16.0 and from there newer version of Theia will also match. The CLI tool can then be used to actually target any specific version that matches those ranges.