Redwood: 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.