Skip to main content


1. Prepare the debugging target

First we need an application to be used as a debugee (app being debugged). Rather than creating such application sufficiently complex to illustrate debugging practices, we will use the well known application, built in the course of the Redwood Tutorial. This application (Redwood Blog) exists in this repository, and we will build it using the information from what's Next Redwood Tutorial section.

Make a local clone and run it, using the commands defined in the section using the example repo of the Redwood Tutorial. The commands to build this app are copied below for your convenience

git clone
cd redwoodblog
yarn rw prisma migrate dev
yarn rw prisma db seed
yarn rw g secret
yarn rw dev

resulting with the front end of the Redwood Blog application running in the browser

Image 1 - running `yarn rw dev` in the terminal (on the left)

2. Setup the Chrome debugger

We are introducing the latest approach available since August 2022 which greatly simplifies access to Authored and Deployed code as explained in the article Modern web debugging in Chrome DevTools.

Having the Redwood Blog app running in the browser (Image 1, above), invoke the DevTools from the browser menu by pressing the F12 key (the DevTools panel is set to be outside and on the left the browser window as shown on the image 2)

Image 2 - invoking DevTools panel to be outside the browser

Click on the Devtools settings icon, then select the Experiments category and click the "Group sources into Authored and Deployed trees" checkbox, as shown on the image 3 below:

Image 3 - select "Group sources into Authored and Deployed trees"

Note: the browser panel with Redwood Blog is placed next to the devtools panel only as a convenience (so you can switch to the browser window and restart the application for example). Having just a single monitor, you can do everything on the devtools panel alone (closing the browser). Alternatively the layout shown on the image 4 below, shows the browser panel mostly covered by the DevTool panel.

Note: the Sources panel is selected on the top menu bar (make sure to learn about all new features available, like view files, edit CSS and JavaScript, Create, save, and run Snippets and Set up a Workspace.

Image 4 - Four important areas of the sources panel used in app debugging

Area 1

shows the application tree view in two formats *Authored and Deployed. We will use the Authored view in the subsquent descriptions of the debugging exercises.

Area 2

depicts the source code view of the item selected in the application tree view (Area 1). The source code is rendered as originaly written Javascript / Typescript code.

Area 3

presents the detailed information about the context of the currently hit breakpoint:

  • list of defined watch variables
  • list of existing breakpoints
  • current application scope
  • call stack
  • list of enabled XMR/fetch breakpoints
  • list DOM breakpoints
  • list of global listeners
  • list of event listeners breakpoints
  • list of CSP violation breakpoints

Area 4

This is the browser rendering the app, partially hidden behind the DevTools panel.

3. Example of use

Let's finish this Setup DevTools debugger section by showing hot to set a breakpoint in the BlogLayout.js layout component. In order to illustrate the stepping process, we will set the brekpoint at the line 57. This situation, rendered by the Chrome debugger is depicted on Image 5, below:

Image 5 - example debugging BlogLayout.js component

Red marker 1 shows the authored source tree, with the component BlogLayout.js presented in the source panel (red marker 2). Note that the only breakpoint is set at line 57, which is also shown i the breakpoints list (red marker 3). Lastly the top of the right panel (detailed information about the context of the currently hit breakpoint) states that the debugger is paused (becuse it hit the breakpoint at line 57).

The next three screenshots show the Local scope, the Closure and Global scope at this breakpoint

Image 6 - Local scope

Image 7 - Closure

Image 8 - Global scope

In addition to this information we could define a set of watch variables, watch / breakpoint on threads, set DOM breakpoints, XHR/fetch breakpoints, set Event listener breakpoints and few other pieces of information. The section on using the Chrome debugger for tracing Authentication code in our debugging target application provides more details on using these debugger features.


4. Setup Visual Studio Code debugger

5. Example of use