Support for VS Code Extensions

[bpmct]

The devcontainer spec supports pre-installing VS Code extensions. Could we support this with the code-server CLI (or even the official vscode-server for Remote SSH)?

This came up from a prospect at Kubecon

[aaronlehmann]

BTW, I currently do this outside the context of envbuilder after the container is built:

 # install and start code-server
  if ! which code-server > /dev/null; then
    curl -fsSL https://code-server.dev/install.sh | sh | tee code-server-install.log
  fi
  CODE_CLI=code-server
  if code; then
    CODE_CLI=code
  fi
  mkdir -p ~/.vscode-server/extensions

  set +e
  extensions=( $(sed 's/\/\/.*$//g' */.devcontainer/devcontainer.json | jq -r -M '[.customizations.vscode.extensions[]?, .extensions[]?] | .[]' ) )
  if [ "$${extensions[0]}" != "" ] && [ "$${extensions[0]}" != "null" ]; then
    for extension in "$${extensions[@]}"; do
      $CODE_CLI --extensions-dir ~/.vscode-server/extensions --install-extension "$extension"
    done
  fi
  set -e
fi

[lookasek]

I confirm that support for installing VS Code Extensions based on devcontainer.json is highly anticipated by many users.

[strike]

if ! which code-server > /dev/null; then
curl -fsSL https://code-server.dev/install.sh | sh | tee code-server-install.log
fi
CODE_CLI=code-server
if code; then
CODE_CLI=code
fi
mkdir -p ~/.vscode-server/extensions

set +e
extensions=( $(sed 's///.*$//g' */.devcontainer/devcontainer.json | jq -r -M '[.customizations.vscode.extensions[]?, .extensions[]?] | .[]' ) )
if [ "$${extensions[0]}" != "" ] && [ "$${extensions[0]}" != "null" ]; then
for extension in "$${extensions[@]}"; do
$CODE_CLI --extensions-dir ~/.vscode-server/extensions --install-extension "$extension"
done
fi
set -e

Hi! I would like to apply your solution. What place are you injected these code?

[mafredri]

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:

• Populate vscode specific configurations #43
• Devcontainer customizations.vscode.settings are not honored #89

---

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.

[bpmct]

I wonder if this is something our envbuilder Terraform provider we need to build can solve. It'd be excellent if the envbuilder provider can provide a raw json object of the full dev container file, which then the code-server module could consume (to then run code-server --install-extension ... on a loop). The code-server module also has support for VS Code settings

[bpmct]

Related: #121

[mafredri]

@bpmct In theory I like that idea, but in practice I think pushing this information back to the provider could be challenging and have support for only a limited number of use-cases. One of the issues is that we should also consider the JSON pulled in via Dev container features, this is only available at build time or in the final image. Without a way to propagate this information from envbuilder to provider, it'd be challenging to do in a robust way.

Two options I think are feasible (for support in e.g. code-server module):

1. Allow running envbuilder read-configuration to have envbuilder produce the JSON
2. Provide a well-known place (or env variable) where the finalized JSON produced by envbuilder is available

I like option 1. since it's what @devcontainer/cli does and allows inclusion of additional JSON. If we match @devcontainer/cli API here and alias envbuilder -> devcontainer, we could make this a very generic solution for anyone building devcontainer functionality that just works ™️ in envbuilder.

Option 2 is more limited but means we don't need to support an API/CLI args.

[bpmct]

I like option 1 too :)

[mtojek]

@mafredri to resolve this issue in favor of smaller subtasks

[mafredri]

This has now been broken out into separate features.

• Provide a way for programs to know they're running inside a devcontainer/envbuilder workspace #212
• Allow generating/accessing a computed devcontainer.json inside an envbuilder workspace #211
• Add read-configuration subcommand to output a merged devcontainer configuration #210
• Allow coder modules to automatically install devcontainer customizations modules#253

Closing this issue as not planned.