Shopify / Shopify/ruby-lsp

Debugger: support remote debugging by mapping local paths to server paths

Open
#1,765 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement help-wanted pinned
Dominant language
Ruby
Stars
2k
Forks
281
Avg merge
2h 14m
Merged PRs (30d)
6

Description

This feature is VS Code specific
  • VS Code specific
Use case

The goal is to be able to debug a Ruby process that is run on a different machine than the current one.

Description

To do that, there must be a mechanism to translate server paths to local paths.

  1. Set up socket forwarding: ssh -L /tmp/ruby-lsp-debug-sockets/ruby-debug-worldmodern-0.sock:/tmp/ruby.sock user@server
  2. Start Ruby on the remote server: bundle exec rdbg --open --command --sock-path=/tmp/ruby.sock -- puma
  3. Attach a debugger (request=attach) as if it's a local server.

This works. However, no breakpoint will trip because breakpoints are set as /home/nowaker/projects/worldmodern/app/controllers/whatever_controller.rb:123 but the server sees it as /var/www/worldmodern/app/controllers/whatever_controller.rb:123.

We need a way to define path mappings, similar to how other VS Code debuggers support it (see PHP):

    {
      "name": "Rails (attach)",
      "type": "ruby_lsp",
      "request": "attach",
      "pathMappings": [
        {
          "localRoot": "${workspaceFolder}",
          "remoteRoot": "/var/www/worldmodern"
        },
        {
          "localRoot": "${env:GEM_HOME}",
          "remoteRoot": "/home/ec2-user/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0"
        }
      ]
    },

Mappings for project directory and gem directory are a must-have to make it work.

NOTE: Debugging as such works. Nothing needs fixing here. I can pause (F6) and I'll see wherever Puma was processing a request. I can them step over, continue, etc no problem.

It's just the path mapping that needs to be provided to visually set up breakpoints locally, and make them trip on the server.

Implementation

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked vscode-php-debug examples in src/phpDebug.ts and src/paths.ts, then trace the Ruby LSP debugger attach and breakpoint path handling. Define how localRoot and remoteRoot mappings should be configured for project and gem directories, and verify that local breakpoints are translated to server paths and trip during remote debugging.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby, vscode
Domain
devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.