launch.json: add ability to set `cwd` for program being launched

[snickell]

This feature is VS Code specific

• [X] VS Code specific

Use case

If your rails app is in a sub-directory of the ${workspaceFolder}, you cannot launch.json it with ruby_lsp:

    {
      "type": "ruby_lsp",
      "name": "Debug rails server",
      "request": "launch",
      "program": "bin/rails server",
      // BUT, root of our rails app is `dashboard/`,
      // and rails doesn't like to be run from the wrong directory:
      // "program": "dashboard/bin/rails server", // => error
      //
      // So, we need to specify the cwd:
      // "cwd": "${workspaceFolder}/dashboard",
    },

Description

Extend the ruby_lsp launch.json for request: "launch" to support a "cwd": "${workspaceFolder}/subpath" field.

Implementation

No response

[vinistock]

Thank you for the feature suggestion!

Can you go into a bit more detail about your project's setup? Is the top level another Ruby application? Do you have other Ruby applications inside the same parent directory?

This feels like a good candidate for using multiroot workspaces. If you have VS Code configured with multiple workspaces, then moving the launch.json inside the Rails app should make it just work.

For example, we are transitioning the Ruby LSP repos (vscode-ruby-lsp and ruby-lsp) into a monorepo structure and that's exactly what we do. The VS Code extension has its launch configurations in its sub directory and then we have a workspace configuration file to declare the different workspaces.

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[snickell]

The structure is that we have our JS frontend code as a sub-dir of the main repo, and our Rails backend code as a sub-dir of the main repo. They all function together, its not really separate projects, it just happens that the root of our rails code is one directory down from the root of the repo.

I don't think it makes sense to add another file (.code-workspace) to the root of our repo to get "rails debugging in vscode", in particular, I think non-VSCode users wouldn't love it. So far this is the only context we've run into where CWD can't be set, e.g. nodejs launchers, task launchers and npm launchers all permit setting the CWD.

[vinistock]

its not really separate projects

Separate workspaces aren't necessarily separate projects. It's just a way to organize the project so that VS Code extensions can easily figure out where the root of workspaces exist (where to find Gemfile, package.json, etc).

This is exactly the setup we have in the Ruby LSP's own code. Both the server and VS Code extension are in the same repo, but we organize it into workspaces.

I think non-VSCode users wouldn't love it

Can you expand into why this is the case? Why would non VS Code users care about a VS Code specific file? Both launch.json and .code-workspace files are VS Code specific, so why would that impact users from other editors?

[snickell]

I think this is my strongest argument in favor of adding cwd: MS launch.json's (e.g. c++, nodejs, python) all support cwd, using the same keyword.

I realize you have an approach to this inside shopify (multiroot workspaces), so this may seem odd, but its actually a fairly major change to have people needing to open VSCode using a project file, etc. I'm not sure this is per se the intended goal of multiroot workspaces, at least, that's not how MS describes them, but it seems a reasonable approach for a monorepo with multiple projects.

Adding multiple vscode specific files to the project's root feels to me relatively undesirable and competing for key file real estate, and I do expect some pushback from non-vscode users (though less than in the past). I wasn't going to put launch.json in the root (see #1), at least you don't have to for javascript.

Anyway, no worries, totally fine if ya'll disagree

[vinistock]

I think this is my strongest argument in favor of adding cwd: MS launch.json's (e.g. c++, nodejs, python) all support cwd, using the same keyword.

The commit that open sourced the C++ extension 7 years ago already had support for cwd from the start and multi-root workspaces were only shipped in October 2017. I haven't checked for the other examples, but it could be that multi-root workspaces didn't exist when these tools added support for cwd.

Especially considering that multi-root workspaces solve this problem in a much more general way. You configure how your repository's workspaces should be organized once and every VS Code extension gets to hook into that and launch properly.

We use this to know where to launch the language server as well, so that we can hook to your Gemfile and automatically index your dependencies without requiring any manual configurations. In fact, unless you're opening VS Code on the sub-directory where your app lives, you're probably not getting the most out of the Ruby LSP. Without workspace configurations, we don't know that the server is supposed to launch from a place different than root and you're likely not getting your dependencies automatically indexed.

If we were to support cwd for the debugger, we would also need to support it for the language server. But since you can have multiple projects inside the same monorepo, then we would need to allow users to configure an arbitrary number of language servers all with their own cwd so that we know where to launch them. At a certain point, we're basically re-building multi-root workspaces from scratch rather than using what the editor already provides.

All of that said, the team agreed to keep this issue open and gauge interest from the community. However, I really believe workspace configurations are the way to make the most our of a repository with multiple sub-workspaces in VS Code.

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months