I’m using Meteor 1.2 and the latest version of WebStorm 11.
Client-side debugging works fine, at least using the Chrome Web Inspector, client-side logging is shown in the console.
My issue is I can’t get server-side debugging to work. I’ve now tried all of the following to no avail:
Running meteor debug and launching Node Inspector (it hooks into my Meteor instance but doesn’t log anything server side or hit any breakpoints I’ve set using debugging; statements in the code, code execution was not suspended)
Launching Meteor from WebStorm, putting console.log() statements all over the place. Nothing would get printed, breakpoints wouldn’t be hit
Running meteor shell and trying to see logging there
Using Atom IDE instead, however this is not suitable for me because of a company proxy which the Atom plugin manager isn’t able to circumvent (doesn’t route proxy info).
Looks like this was a side effect of upgrading to WS 11 from WS 10 without doing a clean install. After completely uninstalling WS 10 and cached settings and installing WS 11 this now works.
Did you sort this out? You did not mention that you had set the NODE_OPTIONS env variable. It is another option for debugging. See article here: http://www.meteorpedia.com/read/Debugging.
You said that you used the debugging; statement? I think you need to use debugger; statement. I am getting debugging; as undefined. debugger; statement will break into the debugger.
Also, note: there are a couple of interesting twists to debugging.
1: Debug non-initialization code for flexibility use NODE_OPTIONS=--debug. What happens is the debugger is connected when the node-debug command is executed. The process will be running and this is typically after all initialization has taken place. This is fine for non-initialization debugging sessions. e.g. you have a breakpoint based on a user action somewhere in the code.
NODE_OPTIONS=--debug is flexible because a debugger does not need to be attached, it is just that it can be. So you can just leave this environment variable and simply attach a debugger when you encounter a problem. Note: debugger; statements have no effect unless a debugger is attached. Useful while developing code.
2: Debug initialization code. Break into the debugger at the start of the process. Either use NODE_OPTIONS=--debug-brk or you can use the meteor debug command. This will break the process into the debugger at the start. When you start the debugger it will be at the beginning of the process and paused. Then all of your breakpoints set in the initialization code will be hit. If you use debugger; statements with a NODE_OPTIONS=--debug state the debugger; statements will not be hit until a debugger is attached.
meteor debug or NODE_OPTIONS=--debug-brk is inflexible because a debugger MUST be connected to continue the process, but it allows you to get at the initialization code.
One way to go is to simply leave NODE_OPTIONS=--debug during development. When you hit a coding bug, just connect a debugger. If you hit an initialization code bug you can restart and run meteor debug.
Also note: console.log statements need to be in the server code to be seen in the console that you used to start the meteor process. If they are in the client then they will show up in the debug console of the browser session.