Since Meteor 1.6 is nearly out (presumably, as it’s on 1.6-rc.6) I wanted to see if I can get debugging working properly with VS Code. I got it working!
meteor run --inspect-brk --settings settings-development.json
Now I can start my server, and then launch the debugger and go on setting break points. It’s been a while since I actively used a debugger, but I remember it being very useful, and am excited to see if it improves my workflow for Meteor dev.
When running this against a server instance, it requires pressing the play button between each save. Is there a way to get that to happen automatically?
Oh right! I guess I just have to use the right one depending on what I am debugging (-brk for startup stuff, so I can set break points, and no -brk for everything else).
I now have a couple of scripts in my package.json file:
"scripts": {
"start": "meteor run",
"debug": "meteor run --inspect",
"debug-brk": "meteor run --inspect-brk"
},
Personally I leave --inspect on by default as there’s no noticeable overhead and it saves restarting the server when you notice something and want to debug.
Debugging is now really easy thanks to 1.6 but the only slight issue I still have is using the Debugger for Chrome plugin in VS Code, when an exception fires in the debug console it doesn’t reverse lookup the sourcemap for each line of the exception, just the one that prints it, which in a Meteor app is the Meteor._debug function. If I open the console in Chrome each line is clickable so I can actually go to where the issue is. Anyone know if that’s fixable with some config ? Or do we need some work from the VS code team ?
Can we have some official documentation about the new way to debug in Visual Studio Code?
I noticed a reference to MacOS for runtimeExecutable in the launch.json example, so I just set runtimeExecutable to null, which seems to work in Windows OS.
I’ve tried this settings and they work all right for the app code, but I still cannot set breakpoints on packages. My project has several packages which are embedded into the main project source code (under the /packages folder) and the only way I can set breakpoints is by adding a ‘debugger’ statement to wherever I need them. Is there a solution for this?
Are you on Windows? This config example has debugger settings for 2 targets - the node.js server, and Chrome. Only the Chrome example has a reference to MacOS, but it shouldn’t effect the node.js settings (I usually only use the server debugger).
Yes I’m using Windows. I just changed runtimeExecutable to null and it seems to be OK.
I’ve only started playing around with debugging in Visual Studio Code and I think I’ve got things working for both client-side and server-side debugging.
Even though Visual Studio Code says that some breakpoints are ignored because of a possible source map problem, they still work.
Ok and thanks for the prompt reply. The problem with packages seems to be that Meteor internally “repackages” the source code, and then the references on .map files become invalid. For example, for a source code stored on the folder: app_root/packages/my_package/server/my_code.js, meteor repackages this using the “meteor” package naming, which is really the name information from the Package.describe() method on the main package.js file.
This makes it impossible for any debugger to match the name stored on the .map file to the real name of the source code, even using localRoot, remoteRoot or outFiles parameters. I think the only way for making this work is if Meteor corrects the name reference in the generated .map files.
I haven’t been able to get server-side Node debugging working myself though - it terminates after a few seconds. Client-side code debugging works fine. Has anyone had this problem and solved it?
Something changed recently which makes the attach part work a bit weirder - I think you just have to press something in the VSCode floating controls. Once you do it once, it automatically connects the next time. They added a drop down too, so you can switch between the server and the client debuggers. It still works, but it’s less automatic.
Update: Oh I remember what I clicked - on the bottom of the VS Code window there is a button that says “auto attach” - I toggled that on, and then it started auto-attaching again.
Auto attach is definitely the way to go now folks. Just add the --inspect or --inspect-brk flag to your start script and turn on Auto Attach – there’s a command for it. It’s really painless now days. (Sometimes it tries to attach to Meteor’s build process which doesn’t work and interrupts your flow with a pop up which is really annoying but it’s just one more click )
)