I've been exploring solutions to this issue and the approach that stands out the most is that we support installing extensions from devcontainer.json within Coder modules and via Dev Container features.

Currently, envbuilder lacks awareness of both VS Code Server and code-server. It makes sense for envbuilder to remain agnostic about specific customizations.

If we look at Codespaces, the VS Code extensions from devcontainer.json are installed as part of the integrated editor for the Codespaces container. The editor is not actually defined in the devcontainer.json, it's a feature of Codespaces. If envbuilder shipped with an integrated editor like Codespaces, then placing that logic within envbuilder would be sensible.

The use-case that we probably should enable (either via envbuilder itself of @devcontainer/cli) is to allow composing a devcontainer.json that is resolved from the projects devcontainer.json and features. Then documenting how to use this.

Examples of this exists in Tool Examples over at @devcontainers/cli.

We can observe that e.g. tool-vscode-server has scripts for both composing the devcontainer.json and installing extensions.

Thoughts? How should we take envbuilder forward?

Related issues:

Side-note: I've also noticed that the "entrypoint" from Dev Container features doesn't get launched via envbuilder. Similarly, envbuilder doesn't respect the final CMD (or ENTRYPOINT?) in container images and replaces these with its own "sleep for infinity", even when the init script is ommited. It's a bit unclear to me how we should handle this.

Support for VS Code Extensions #68

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions