Investigation: The VSCode Server injected by Editor injector is not self-contained/portable
Problem statement
While updating VSCode Fork from v1.81.1 to v1.85.2, we discovered that we are not producing a portable/self-contained version of vscode-server
that can be injected into any Docker image regardless of the underlying operating system and version. A self-contained editor injector is a hard requirement for the Remote Development's Workspaces feature. We've been shipping the editor injector since inception under the assumption that we are producing a self-contained artifact in the CI environment.
While trying to run a version of the editor injector produced with version 1.85.2 of the vscode-server
, the vscode-server
failed with the following stacktrace:
The stacktrace contains evidence that the VSCode Server dependencies that are bindings to system libraries can't find the expected version of those libraries installed in the os.
What is the root cause of this problem?
VSCode Server depends on native system libraries that it accesses through Node bindings. These node bindings are compiled using dynamic linking therefore they expect that the system libraries are installed somewhere in the system. Some of these libraries are:
@parcel/watcher
node-pty
@vscode/spdlog
When running the server, if the system dependencies with correct versions aren't installed, the server fails.
Open questions
- Are existing versions of the editor injector self-contained? If the answer is no, should we identify the minimum system requirements to run this tool and report them to our customers?
- Should customers be able to choose between several releases of the editor-injector if we don't find a way of making this tool self-contained?
- Should we decouple the editor injector from the VSCode Fork project such that the editor injector can target an older version of VSCode if necessary?
Proposed solutions
- We might be able to create a portable version of VSCode server using https://www.npmjs.com/package/pkg