Add option --inspect dev-server

[peterp]

When you run yarn rw dev we launch two processes:

1. webpack dev server
2. redwood dev server

yarn rw dev
yarn run v1.22.4
$ /Users/peterp/x/redwoodjs/example-invoice/node_modules/.bin/rw dev
$ /Users/peterp/x/redwoodjs/example-invoice/node_modules/.bin/dev-server
$ /Users/peterp/x/redwoodjs/example-invoice/node_modules/.bin/webpack-dev-server --config ../node_modules/@redwoodjs/core/config/webpack.development.js

I would like to have the ability to pass --inspect in the dev-server: yarn rw dev api --inspect

[peterp]

I really think this stems from the issue that we don't yet have a decent story for passing arguments to the sub-commands. --forward is sort of there, but not exactly working in a nice way:

1. --forward should only be usable when you specify a side.
2. it would be great if we didn't have to wrap it in strings.

I wish we could do the following yarn rw <command> <arg> <arg> -- <get everything after -->

[dac09]

What do you think of a separate command yarn rw dev:inspect or yarn rw debug instead? Might give you more room to change things!

[peterp]

Those both seem like reasonable suggestions, I really like the idea of a debug command that we could expand to include "more sides", but that right now would only target the api side.

$ yarn rw debug [api]

> api is already running on port 8911
> shutting down api...
> starting api on port 8911 with --inspect
> note: once you're done debugging you'll have to manually restart the api via `yarn rw dev api`

[aldonline]

Glad to see we're getting to debugging :)

A few notes on debugging:

Sourcemaps

In order for any kind of debugging to work, one of the most important requirements is that sourcemaps for all the sources that end up participating at runtime (both client and server) are present and correct (and correctly linked/made available to the runtimes). Most compilers and bundlers such as webpack provide good sourcemap support out of the box, but tinkering with things like Babel macros can easily break them. A while back I tried to implement debugging and I ran into a few walls here, but I figured that it was lower priority (make it work, make it right, make it fast), so I didn't bring it up. We can always fix sourcemaps manually if they are broken. I haven't tried with the current version of Redwood so I don't know how things stand. Just keep it in mind if you run into issues (ex: breakpoints not being correctly set).

Processes

There are two processes that Redwood users may want to debug:

• The lambda dev server
• The browser process

There is a third process: The webpack-dev-server process itself. Unless you're a Redwood framework developer, it is unlikely you'll want to debug it.

Lambda dev server (api side)

This process is owned by the CLI. Therefore, the CLI is responsible for starting the sub-process with --inspect.
We need to implement this. Instead of reinventing the wheel, we could allow users to pass all of Node.js's debug related command line options or, as @peterp suggests, have a generic mechanism for forwarding like -- (ex: yarn rw cmd -- a b c=d).

Browser process (web side)

This one is not our responsibility. Tools such as VSCode have the ability to launch Chrome in debug mode and leverage the DevTools protocol to enable debugging. If the sourcemaps are correct (which is our responsibility) then this is an IDE + Webpack affair.
We just need to provide a cookbook with instructions. I will also provide a launch configuration automatically when using Decoupled Studio.

[adriatic]

@aldonline @thedavidprice am I right assuming that this discussion did not move ahead from this point? I would like to pick it up enough to be able to write the debugging chapter for the Developing Redwood apps on Windows, so I would appreciate to learn about advancements Aldo has made. Note that before stepping into VSCode extensions (that is Aldo’s main drive), I would like to define the feature of simultaneous debugging the “app” and the “web” side using a single VSCode instance.

@peterp do you have any comments for me?

[alecswan]

I've spent a couple of hours trying to get debugging to work in VS Code to no avail. My latest attempt is shown below where I call node executable with --inspect argument and also delegate application deployment to yarn. My application does start up and runs fine but VS Code doesn't break on any of my breakpoints work. In fact, VS Code shows my breakpoints as deactivated with "Unbounded breakpoint" on hover over.

Any thoughts on the direction I am taking and why it's not working?

The following isthe launch config I added to "configurations" in VS Code's launch.json:

{
      "trace": true,
      "type": "node",
      "request": "launch",
      "name": "yarn rw dev",
      "cwd": "${workspaceRoot}",
      "runtimeExecutable": "/home/alec/.nvm/versions/node/v14.17.4/bin/node",
      "runtimeArgs": [
        "--inspect",
        "/home/alec/.nvm/versions/node/v14.17.4/bin/yarn",
        "rw",
        "dev"
      ],
      "sourceMaps": true,
      "smartStep": true,
      "internalConsoleOptions": "openOnSessionStart",
      "outFiles": [
        "${workspaceFolder}/api/dist/**/*.js",
        "${workspaceFolder}/web/dist/**/*.js"
      ]
    }

[thedavidprice]

@alecswan the upcoming re-write of the Redwood VS Code Extension does have debugging working, but it's not ready for release yet.

@aldonline (he's the extension author) do you have any tips or direction here that could help near-term?

[alecswan]

Thanks, @thedavidprice, the absence of a way to debug redwood apps makes it hard to advocate for RW even for PoCs. Even a list of manual steps to get the app running and pausing at breakpoints (in TypeScript) would be a huge help! @aldonline, do you have any such steps or insights you could share?

[jtoar]

Create redwood app now ships with a launch.json for the api side: #4904. And debugging documentation is in process.