Support both container volume and bind mount workspaces with single docker-compose devcontainer config

I maintain devcontainer configurations using docker-compose for several repositories, and I need to have compatibility with both volume mount workspaces, and local bind mount workspaces. e.g. so that cloning a repo into a container volume via the VSCode command palette, and opening a local checkout of the repository both work consistently.

The plugin / devcontainer.json doesn't seem to explicitly provide a means to handle this. e.g. the documentation for docker-compose devcontainers shows configs which hard code a local bind mount referencing the workspace repository root, e.g. ..:/workspace. This of course doesn't work when the workspace is in a container volume. But when the docker-compose file omits such a local bind mount and the workspace is in a container volume, the plugin will automatically mount the container volume at /workspaces and the working directory in the container will be /workspaces/<name>. (But omitting the local bind mount does not result in one being automatically created.)

These two behaviours are mutually-exclusive. And there isn't a way to reference the workspace's container volume to mount it into one of the docker-compose services that isn't the container volume. So to achieve a single configuration which supports bind mounts and volumes, I run a shell script in the devcontainer.json#initializeCommand which detects if the workspace is being opened from a local bind mount or container volume, and generates environment variables in a .env file which can be referenced in docker-compose.yml, so that we can have a single devcontainer config that works for both situations.

The two recent releases of the remote containers extension (0.232.2 and 0.232.3) have changed the behaviour of devcontainers using volume mounts for their workspace files. Because the plugin is not open source, and details of changes between versions don't seem to be provided, it's proving hard to maintain this compatibility. (After 0.232.2 I had to go through all my docker-compose projects and rework the devcontainern configs to get them working again, and now 0.232.3 has changed the behaviour again, so I've got to work out what's changed and do this again.)

If I'm not mistaken, the 0.232.2 release changed the ${containerWorkspaceFolder} placeholder to always evaluate to the workspaceFolder property (e.g. /workspace) for both volume and bind workspaces; previously it was not expanded for volume workspaces (e.g. it was literally ${containerWorkspaceFolder}). And the working directory in the devcontainer changed to be always the workspaceFolder value, so I had to cd explicitly to the /workspaces/<name> path in container workspaces. Now in 0.232.3 the behaviour seems to be that ${containerWorkspaceFolder} expands to the /workspaces/<name> path for volume workspaces, and this dir is the default working directory again.

I think It would be useful to define a consistent way to get the workspace files mounted in a container. One option might be to define a particular label, such that that when a container is marked with the label, the plugin automatically handles creating the appropriate bind or volume mount for the workspace code to the container. The label could also be applied to other service containers to request the workspace content be made available at a particular mount point.