How does Theia support hot-swapping functionality?

[wangding001]

Currently, I have a Theia extension, and I want to convert it into a VS Code extension to achieve hot-swapping. However, these are two separate processes, and my Theia extension has many dependencies, such as relying on Theia itself and other related extensions, as well as numerous pages. I initially thought converting it to a VS Code extension for hot-swapping might not be realistic.

So, I want to know if Theia extensions inherently support hot-swapping. Right now, I see that all extensions are bundled into a single bundle.js file, which seems to make hot-swapping impossible. How can I modify this to enable hot-swapping for extensions?

[msujew]

Hey @wangding001,

Theia extensions are by design compile time - there is no way to perform hot swapping on them, at least as far as I know. Perhaps there are other ways to accomplish what you're looking for? You could, for example, simply disable your own widgets if they are "deactivated".

[msujew]

Most notably, Theia plugins can also be used directly on the frontend, whereas VSCode extensions are limited to the backend. As a result, Theia plugins can directly manipulate the UI without going through the webview abstraction, simplifying the development process.

This is not correct. Where did you get this info?

Just like in VSCode, you can build a browser plugin, but that runs in a webworker - and as a result also only has access to the plugin API. You will never get direct UI access through a webworker.

[wangding001]

I will now forcibly change Theia's extensions to a hot-plugging approach as follows:

Based on Webpack's Module Federation mechanism, for a Theia extension, modify its webpack.config.js file so that all its shared dependencies use those from the main program. The main program's webpack.config.js should expose the required capabilities for the extensions to use. If certain dependencies are missing in the main program, they should be added there first.

Then, modify src/gen to ensure that the bundled output of this extension is integrated into the container. The final implementation involves packaging the extension as a VS Code plugin and placing its bundled output in a directory, effectively running it as a single process.
Here are the details:

Independent Packaging of Extensions: Each extension is bundled independently via Webpack, generating a standalone bundle that includes the extension's own code and its dependencies, avoiding tight coupling with the main application.

Decoupling the Main Application and Extensions: The main application shares dependencies with extensions through Webpack's shared configuration. The main app only needs to maintain common dependencies, while extensions can be upgraded or replaced independently.

Runtime Loading by the Main Application: The main application loads extensions at runtime, requiring only a restart or refresh to apply changes.

Integration with VS Code Lifecycle: Loading and unloading of extensions follow VS Code's lifecycle management.

[msujew]

This text is AI generated, right? I'm sorry, but the approach you're outlining doesn't make any sense.

[wangding001]

No, this is actually a solution I came up with based on my own practical implementation.

[msujew]

With practical implementation you mean you already have some working implementation of the hot swapping feature? I'm a bit confused by how the VS Code plugin lifecycle plays into this, since the lifecycle is happening in the plugin host, which runs as a separate process/webworker.

The final implementation involves packaging the extension as a VS Code plugin and placing its bundled output in a directory, effectively running it as a single process.

However, here you're saying that it runs as a single process. Something doesn't match up here.