Skip to content

[Feature Request]: Full VS Code Support #1001

@jrseliga

Description

@jrseliga

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.
Screenshot from 2023-05-12 22-28-16.

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.

Screenshot from 2023-05-12 23-03-35

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.

Screenshot from 2023-05-12 23-06-33

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions