Support vscode container description .devcontainer

[maxklock]

Tell us about your request You use the vscode remote development feature, but you implemented your own configuration system. Why not support .devcontainer configuration? I've already added those files to some of my repositories and now I would have to change everything to your custom system.

Which service(s) is this request for? Single container and Compose based dev environments

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? For my environments I sometimes need specific extensions or need to configure external mounts. With .devcontainer this is already possible, but not with .docker configuration.

Are you currently working around the issue? Currently i would not using dev environments. Instead i would directly use the vs code remote container system.

[BitPatty]

+1

I was silly and assumed this already works out of the box when trying it out initially with one of my projects. Having to create and maintain a second configuration makes things both confusing and cumbersome.

While it's probably not as easy to maintain compatibility between the two systems I (and I'd bet many other people) would prefer not to clutter repositories with even more configuration files if there's already a very similar and stable solution out there. Especially since dev environments appear to use the remote containers extension under the hood as well.

[EliiseS]

I thought it worked out of the box too with .devcontainers and I will not use this feature until it does

[corradocavalli]

I agree with @EliiseS, .devcontainers is the way to go.

[nebuk89]

Thanks for the feedback all :) we know that people <3 dev containers, but we are also looking at supporting other IDEs (initially some Jetbrains bits and Theia). To enable this we are looking at using Compose as agnostic and something all users could pick up.

We are looking at if part of that path is supporting the devcontainer.json on route and will keep you updated as we review this :)

[ThePlenkov]

I had too many hopes for this feature. I agree - so far is a total disappointment. Well - there are good things for sure - it's a great idea to use docker desktop as a workspace to keep all dev environments in one place. However the experience is not nice so far:

• there is no way to regenerate dev environment. Yes - we can clone a new project - but if I changed compose yaml ( let's say changed base image version ) - there is no way to rebuild it. Deletion of the project - is not a choice - cause in this case you also loose you built and local artifacts. So rebuild feature is very needed
• it's very weird to observe that Docker team is trying to reinvent the wheel - i mean - dev containers already became de-facto a standard and it's a separate spec now, not even belonging to VS Code: https://containers.dev/. I mean if we have devcontainer.json ( backed by compose for example ) - why not just to use that set up somehow and let's say generate container-dev.yaml on the fly if it needs it ( i think it;s exactly what VS code is doing too )
• Connecting to running container in VS Code is not the same as running workspace in a devcontainer. VS Code module installed in a dev environment doesn't deliver features fully. Just for example - it's not possible to debug TypeScript from debug terminal in VS Code, connected to such a compose. I don't know why, probably a bug in VS Code - but still - there is no alternative - dev environments are not usable in the current state for our scenario.
• One more reason to support devcontainers - is to have an option to open the project in Github codespaces. Yes, gitpod went their own way by introducing gitpod.yaml - but I think people will be bored soon to maintain same things in two different places and gitpod.yml will loose do devcontainers in the end. There is a ticket and you can see how large the interest is: https://github.com/gitpod-io/gitpod/issues/7721. But point is - at least Gitpod works well and fast with ability to make snapshots and share environments, but which additional value brings compose-dev.yaml? Ability to open from Chrome? You can reach way more interest if you let users to open any projects in Codespaces-like way on the local machine. That will bring a real value - especially for large projects requiring resources extending free tier on Codespaces/Gitpod..

[rickyjames35]

This issue brings up a lot of good points that I'm hoping are being addressed in the new version that will be released in the coming months. Here is the admonition in the documentation about the new release:

Dev Environments is changing

We’re working hard to make Dev Environments work even better for you and your teams. In the coming months, we’ll be introducing a new vision for Dev Environments.

In the mean time, it may take us longer to respond to requests for support.

If anyone has more info on the upcoming changes please post a link.