Background

I'm looking at dev containers more and I've been aiming to have a single repository to manage both my own:

• features
• dev container configurations

The current spec makes reusing local features between dev container configurations trickier than perhaps it could be.

I have managed to achieve this in some form, but it involved both considerable workarounds and considerable trial and error to see what would work.

Benefits of local features

Why are local features useful?

For individual developers trying to manage a collection of their own common configurations for reuse, local features running directly from files are nicely lightweight. Local features let you:

• avoid building, publishing and managing full-blown feature packages
• change the configuration and have those changes take direct effect on next dev container build, without any further steps
• keep features private easily, without worrying about usage quotas/hosting costs (example: GitHub charge for private package use)¹

The current restrictions

There are restrictions in the specification on where features are stored: they must be in the workspace root.²

Clunky workarounds are needed to be able to have a working local feature stored elsewhere, more "centrally", and not only in a specific configuration for a specific dev container configuration.

Problems and current workarounds

Local features do not support VS Code's alternative dev container configuration paths

• VS Code offers a way to specify alternative paths for dev container configurations, other than the original source repository folder itself.
• When you open the source repository folder, the dev container configuration stored elsewhere is then used.
• This is good: it gets part way to managing dev container setups in a completely separate path, which could also be a version controlled repository itself.
• Unfortunately, move your entire functioning dev container configuration from the repository to an alternative configuration folder doesn't work. The dev container will start to build. But the features are no longer found within the .devcontainer folder in the workspace root. Building the dev container then fails.
• (Maybe there are workarounds of linking the features back in to the original source repository here? But this is particularly messy.)
• I described a workaround in a vscode-remote-release issue where you instead open the dev container configuration folder, and specify the intended repository folder as a mount. This finds the features as part of the workspace root then, and builds correctly.

Local features still can't be easily reused, even then

• Even with the workaround above, this still does not give me a way to easily create the same feature once, and then re-use it.
• Further workarounds to have one canonical "source" feature, but get the feature files in place inside the dev container configuration are needed, such as:
  • hardlinking the shared feature files into each dev container configuration where they are used (symlinks are insufficient)
  • adding the shared features to a Git submodule containing all features, pushing that, and cloning it within each dev container configuration for use

All this just about works 🔧, but has a lot more friction in doing so.