-
Notifications
You must be signed in to change notification settings - Fork 270
Description
To start things off, the experience of getting a development environment spun up has been refreshingly painless with devbox.
As mentioned in this post, starting devbox shell
automatically in the VS Code terminal is extremely helpful however it does not sufficiently integrate the devbox environment with VS Code processes (like tasks, debugger, etc.)
As one example, VS Code automatically reads and exposes the scripts defined with the package.json
of the open project.
.
When a task is run, VS Code spins up a process to execute npm run dev
.
However, these processes are initiated from the shell where VS Code was launched. For obvious reasons (npm
only being installed within devbox), attempting to run this task fails, which in some ways greatly defeats the promise of devbox and the power of VS Code.
This "workaround" better illustrates the importance of the shell context VS Code is running in. When code
is executed after entering devbox shell
, we get the expected behavior.
This "workaround" is more a proof-of-concept though as it is full of other compromises to the daily development experience.
This execution of tasks is fundamental to the VS Code platform. They expect extension authors to provide similar features (executing binaries through the VS Code command palette) through this mechanism.
Code linters / formatters, unit testing platforms, dependency management tools, etc. execute directly through the shell.
This is the power of the available Remote Extensions (SSH, Containers, WSL, etc.) provided by Microsoft. To really oversimplify, these remote extensions "trick" VS Code into thinking it is running from within the container or the SSH connection. The "trick" in this case just being that a lightweight "server" version of VS Code is installed in the container / SSH connection. This allows VS Code to execute these tasks with the packages available in that environment instead of those available on your local OS and it's packages (or ideally lack thereof).
Unfortunately (though I would be extremely happy to learn I'm just doing something wrong) the Dockerfile
/ devcontainer
feature of devbox does not provide this tight VS Code integration as it just pushes the problem one layer deeper.
VS Code is "tricked" into thinking it is running in the container, however like a more traditional setup, the devbox packages are not installed in the container, they're installed within the devbox that's installed in the container. The VS Code tasks are then just run in the context of the container shell.
It would be fantastic if the devbox VS Code extension could support this. I tried to look into how the official Remote Extensions pull this off but I do not think they are open source.
Happy to help out if I can.