SuiteScript Client-Side Debugging in vsCode

Every developer should be doing interactive debugging. Here’s how to debug client-side SuitesScript using vsCode. 

Before continuing on, I’d highly recommend you watch this video by James Quick. It’s worth your time. Thanks James!

James Quick’s video on vsCode debugging

Now that you know what’s possible, let’s get this working with NetSuite. There are several ways to go about it.

  1. Configure vsCode to auto-start Chrome and open the URL that you’d like to debug
  2. Configure vsCode to attach to an already-open page in Chrome

Let’s look at my launch.js file. It defines 2 configurations (methods of starting debugging).

Launch File

Here is where I’d select one of my two configurations to start interactive debugging. You can easily see how these dropdowns match my 2 configurations in my launch.js file.


Option #1 – “Sandbox Edit” automatically starts Chrome and opens the specific page I’ve called out in the URL parameter of the configuration. Then it matches any JavaScript files in my vsCode workspace (called out in the webRoot parameter) with files of the same name downloaded to the browser.

In this example, logic_comp_common.js lives locally in my
[vsCode workspace root]\Components\Common  folder. This matches the location I’ve set in webRoot parameter. This lets vsCode and Chrome seamlessly match the downloaded version of the code seen by the browser with vsCode’s version of the code saved locally.

Javascript Associations

When the two files match vsCode lets me set stops directly in my workspace copy of logic_comp_client.js.

Launch Example

Option #2 – “Any URL Attach” tells vsCode to attach to an already open web page. In this case, I click the second option in the dropdown before clicking the green “Play” button to start debugging.

But first (don’t ya hate that)… In order to attach, I need to tell Chome to start in debugging mode. I do this in the shortcut where I launch Chrome. Note! The port specified here must match the one in launch.json. 

Chrome Shortcut Properties

In this example, when I try to set a stop in logic_comp_common.js, the breakpoint will not turn bright red like it did in the previous example. The reason: vsCode cannot correctly associate logic_comp_common.js in my workspace with the file downloaded from the server to the browser.

Attach and set stop

This is because the layout of the files in my vsCode workspace does not match the layout of the files on the server.

Folder Layouts

If the folders had matched, this would have worked. However, I can work around this. If I double-click the file under “Loaded Scripts”, it will open a second copy (the browser’s copy) of the file. Note below that logic_comp_common.js appears in two tabs.

Dev Tools Version of the File

In this copy of the logic_comp_common.js, I can set stops and step through code.

Hopefully, I’ve worked through enough examples of how to launch vsCode debugger and how to associate files in your local workspace with files downloaded from server to browser and set stops. Between my notes and the video, you should be successful in doing interactive debugging in vsCode. That’s where I’m headed! Won’t you join me?


2 thoughts on “SuiteScript Client-Side Debugging in vsCode

    1. Philip, Thanks for your question. What I mean by “matches any JavasScript files…” is that if a file name of a downloaded JavaScript file matches what’s in your webroot (the local file folder specified in the first diagram in my post) then you can set a stop directly in the file you’re writing in vsCode. If the files are not the same name (unlikely) or in a different location on the server (much more likely), then you’ll find that the red dot you see when setting stops in your code does not turn red. It’s been a while since I actually encountered this, so I’m going from memory. What I believe you’ll see is a second file show up in the “Loaded Script” section of vsCode. That will bounce you over into another open copy of the file where you can set stops. I realize this seems overly complicated, but it all has to do with vsCodes ability to match up the file that you’re actively editing with the copy that the browser downloads from the server at runtime. Hopefully, that makes at least some sense.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s