Before I get into the details, please note:
- 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:
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
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.
So how do you do this exactly?
My webstorm doesnt react in any way to the breakpoints I set in server code.
What exact versions of WebStorm/Meteor are you using now?
Meteor 1.1 and Webstorm 12, win7
meteor debug also doesnt respond to breakpoints(
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
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.
Cheers and good luck.