feat: create a new "Install Dev Container feature" module

[phorcys420]

I think we should have an easy way to install Dev Container features in Coder workspaces (even outside of Dev Containers).

My reasoning behind that is that there is already a lot of great Dev Container features that you are currently unable to use with Coder without hacks.

There are also quite a lot of active modules that are used to maintain dependencies and collide w/ Coder modules (e.g nodejs and jupyterlab).

Given these points, I think we could replace part of our modules with existing Dev Container features and maybe migrate some of our existing features to contribute back to the Dev Container ecosystem.

---

Example usage

module "nodejs" {
  source   = "registry.coder.com/modules/install-devcontainer-feature/coder"

  # Ideally could be either a Git URL, a local folder or a path to an image
  # AFAIK the images are only used to store data and not really as proper images.
  feature = "ghcr.io/devcontainers/templates/javascript-node:4.0.2"

  version  = "1.0.0"
  agent_id = coder_agent.example.id
}

[phorcys420]

I have created an issue over @ the Envbuilder repo to discuss how we could maybe add a command that would use the existing feature logic.

https://github.com/coder/envbuilder/issues/361

[matifali]

Do you want this to work on any workspace or only with an existing devcontainer spec?

[phorcys420]

Do you want this to work on any workspace or only with an existing devcontainer spec?

All workspaces.

[matifali]

@phorcys420 The devcontainer feature script should be intelligent enough to exist cleanly if it is incompatible with the workspace image. As per my experience, most devcontainer features are only compatible with Debian/ubuntu images.

[phorcys420]

@phorcys420 The devcontainer feature script should be intelligent enough to exist cleanly if it is incompatible with the workspace image. As per my experience, most devcontainer features are only compatible with Debian/ubuntu images.

I agree, usually devcontainer features already handle that and most of our users are using Debian/Ubuntu anyways, but we can probably wrap it in a try/catch or something just to exit cleanly.