Debug Wasp app in VS Code

Hey all, I'm building a Wasp app with Typescript. What's the best way to debug the server part? I've tried to run wasp start in VS Code integrated terminal and attach to the node process on port 3001, but the debugger hangs after a couple seconds and the breakpoints are not hit. What the process of debugging should look like? Thanks!
15 Replies
anthony.davidson.189
anthony.davidson.189β€’11mo ago
@Wasp Team any suggestions? πŸ‘†
Filip
Filipβ€’11mo ago
Hey @anthony.davidson.189, thanks for trying out Wasp! The debugger isn't working because you're probably placing breakpoints in the server code you've written (under <project_root>/src/server). The thing is, Wasp does not run this code directly. Instead, it uses the functions you've written and generates server code into the hidden .wasp directory. This is the code that wasp start actually runs.
No description
Filip
Filipβ€’11mo ago
More details here: https://wasp-lang.dev/docs Anyway, to answer your question: How can you debug Wasp server code? We don't yet have proper mappings that would allow you to place breakpoints inside your source code and debug from there. I recommend: - Using console.logs πŸ™ƒ - Digging into the generated code in .wasp/out/server/src and placing breakpoints there (it's still human readable) We plan to support proper debugger mappings in the future, sorry that it's a bit of a pain at the moment
anthony.davidson.189
anthony.davidson.189β€’11mo ago
the Thanks for the answer, I've tried to dig into wasp/out/server/src folder, but actions there are not the same as in my code.
MEE6
MEE6β€’11mo ago
Wohooo @anthony.davidson.189, you just became a Waspeteer level 1!
Filip
Filipβ€’11mo ago
Try looking under ext-src, we have our own wrappers around actions (and you probably ran into those) This the path to your code inside the generated code: <project_root>/.wasp/out/server/src/ext-src. It's an exact replica of what you have in <project_root>/src/server
anthony.davidson.189
anthony.davidson.189β€’11mo ago
That works, thanks. But the breakpoints I've set there are not hit. Can it be because the issue in my .vscode/launch.json config is inaccurate?
{
"version": "0.2.0",
"configurations": [

{
"type": "node",
"name": "Attach to Node on Port",
"request": "attach",
"port": 3001
}
]
}
{
"version": "0.2.0",
"configurations": [

{
"type": "node",
"name": "Attach to Node on Port",
"request": "attach",
"port": 3001
}
]
}
Filip
Filipβ€’11mo ago
I'll try it out and let you know, give me a couple of minutes πŸ˜„ Btw, you can copy paste your code here, maybe I can spot the bug (if it's something our users often run into).
anthony.davidson.189
anthony.davidson.189β€’11mo ago
I don't have any code issues yet, but the logic of my app is pretty complex, and debugging it with console.log is exceptionally inconvenient πŸ™‚
Filip
Filipβ€’11mo ago
Ok, no problem. I think I figured it out. In short... When you want to debug a HTTP server process by attaching to it, you don't want to attach to the app's HTTP server port (3001 in this case). This port is only meant for serving client requests and does not have a protocol for handling the communication with the debugger. Instead, your app must expose a "debugging interface" on a different port (e.g., 2000). Node supports this through the --inspect flag. More precisely, if this is how you usually start your server:
node main.js
node main.js
Then this is how you expose a port with a debugging interface (i.e., make it "attachable):
node --inspect=2000 main.js
node --inspect=2000 main.js
Now, since Wasp starts node for you, you'll have to override how Wasp starts node in the generated package.json file. Here's how to get your debugger working: 1. Go into .wasp/out/server/package.json and add the --inspect flag to the start script (as shown in the picture) 2. Change the port in your debug config from 3001 to 2000 3. The breakpoints should work now!
No description
Filip
Filipβ€’11mo ago
Just be careful, if you add a dependency, execute wasp clean, or do something similar, Wasp will regenerate the package.json file, overriding your changes. In other words, if your debugger stops working again, double check whether the package.json file still has the inspect flag. For completeness, here's the correct launch.js config:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"name": "Attach to Node on Port",
"request": "attach",
"port": 2000
}
]
}
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"name": "Attach to Node on Port",
"request": "attach",
"port": 2000
}
]
}
Finally, here's a link with more info on attach debugging: https://medium.com/@saransh98/debugging-node-js-via-vs-code-with-attach-single-process-only-87c50683a8ef Hope this helps! Let me know if you need something else
anthony.davidson.189
anthony.davidson.189β€’11mo ago
It works, thank you very much! I understand why you won't put that into docs though πŸ˜‚ I hope the process improves in the future. Proper debugging is essential for a project more significant than a to-do app, probably makes sense to add it to the backlog Thanks again! πŸ™
Filip
Filipβ€’11mo ago
Definitely! We're currently in the middle of a big project restructuring effort, and debugging will probably be included as well!
martinsos
martinsosβ€’10mo ago
@Filip should we open a GH issue for this? If you think it is not needed ok, just wanted to check!
Filip
Filipβ€’2mo ago
Another user requested this recently, tracked here: https://github.com/wasp-lang/wasp/issues/1998
GitHub
Node.js debugger for the server Β· Issue #1998 Β· wasp-lang/wasp
Some users asked how they can debug the server's Node.js app. Ideally, we would enable the users to use the --inspect with a Wasp flag: https://nodejs.org/en/learn/getting-started/debugging#ena...