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.
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 ?
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).
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.
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 )