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.
- Configure vsCode to auto-start Chrome and open the URL that you’d like to debug
- 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).
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.
When the two files match vsCode lets me set stops directly in my workspace copy of logic_comp_client.js.
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.
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.
This is because the layout of the files in my vsCode workspace does not match the layout of the files on the server.
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.
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?
NetSuite Experiences 
Hi Kevin,
How do you exactly match the js files? (option#1)
quote: “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.”
LikeLike
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.
LikeLiked by 1 person