This sounds better if you never use cloud editor platforms; devcontainer can be useful if you jump between local coding and say GitHub Codespaces where devcontainer.json is automatically recognized.
IME a hybrid of your approach and devcontainers works best in that situation though, because I don't want to rely on or even figure out how to use the devcontainer recipes, and building them every time the thing spins up takes forever. I like a workspace container defined in a Dockerfile that publishes to a registry and a very basic devcontainer config to use it.
I've asked the same question and still haven't got a concrete answer as to why anyone would use devcontainers.
As I understand it, devcontainers use some base image and then instructions in json file with steps what to add for that specific app. Why not just make a docker image with everything your app needs and use it?
Yeah I’ve spent a lot of time digging into devcontainers, and I think the basic answer is that they play nice with VScode/codespaces and not much else.
If you are using those, it gives you a nice push button way to get up and running. If you’re not using those, they’re pretty awkward — you just end up with images/containers that can only be built/run/interacted with using the devcontainer-cli tooling.
Would be nice if there was a simple standard way to point to a dockerfile in your repo (or even an image name) and say “build and run this for the dev env.” And the tools ecosystem could then reference and use standard container tools to build and run.
I imagine that is a bit tricky to optimize for build speed on a monorepo. Say you have 3 things to build you need to pick the order OR you could use multiple targets amd copy stuff around I suppose.
Why? I have a Containerfile to which I add new stuff regularly. I build and run it as my 'workspace' container. Works very well.
This sounds better if you never use cloud editor platforms; devcontainer can be useful if you jump between local coding and say GitHub Codespaces where devcontainer.json is automatically recognized.
IME a hybrid of your approach and devcontainers works best in that situation though, because I don't want to rely on or even figure out how to use the devcontainer recipes, and building them every time the thing spins up takes forever. I like a workspace container defined in a Dockerfile that publishes to a registry and a very basic devcontainer config to use it.
I've asked the same question and still haven't got a concrete answer as to why anyone would use devcontainers.
As I understand it, devcontainers use some base image and then instructions in json file with steps what to add for that specific app. Why not just make a docker image with everything your app needs and use it?
Please reply to this then :)
https://news.ycombinator.com/item?id=41940213
Genuine question. I want to use Docker for local dev loop but speed puts me off. I typically use it for "ready to push" tests.
Check out Earthly :)
Yeah I’ve spent a lot of time digging into devcontainers, and I think the basic answer is that they play nice with VScode/codespaces and not much else.
If you are using those, it gives you a nice push button way to get up and running. If you’re not using those, they’re pretty awkward — you just end up with images/containers that can only be built/run/interacted with using the devcontainer-cli tooling.
Would be nice if there was a simple standard way to point to a dockerfile in your repo (or even an image name) and say “build and run this for the dev env.” And the tools ecosystem could then reference and use standard container tools to build and run.
I imagine that is a bit tricky to optimize for build speed on a monorepo. Say you have 3 things to build you need to pick the order OR you could use multiple targets amd copy stuff around I suppose.
Is the debugging experience good?
[dead]