Can anyone recommend a debugger that works for Meteor 1.8? Since the move to websockets from the old port 5858 protocol, I can’t get any debugger to work dependably. If anyone can recommend a recipe (that I can run on MacOS please), I will spare you all my whining about all the things that haven’t worked for me. 
THANKS! I am a WS user but I had not upgraded to the lastest, and web searches turned up only problems with WS meteor debugging. However that appears to be solved. I installed the latest 2018.2.5 version and I seem to have solid server-side debugging in the Meteor run configuration.
Google take note: debugging Meteor 1.8 in WebStorm 2018.2.5 works great for me.
1 Like
Wish I had waited a bit longer before that pronouncement.
@vikr00001 is there a version of Webstorm that works well for you?
I am seeing much of the same misbehavior that I see with Chrome inspector and node-inspector.
The debugger; statement will break dependably (from what I can tell), but getting the it to recognize other breakpoints is sketchy at best, and worst of all, when stepping through code that crosses a fiber boundary (like any collection call), the debugger will continue and lose the step context.
It seems to me that fibers are the main problem, and it has always been a bit of a problem, but it has gotten bad since node switched to the ws:9229 protocol instead of the old :5858 (I don’t know much about the inner workings of those protocols).
I’ve seen other complaints posted around about this problem or similar so I am sure I’m not alone. Does anyone have a backend debugger solution that is better?
I’m using the latest IntelliJ, which includes WebStorm, and breakpoints work as expected. (Prior to IntelliJ I used the stand-alone Webstorm). I don’t use the debugger statement - I just set a breakpoint in the IDE.
IntelliJ has great tech support. It might be helpful to contact them and get their input on this.
There is currently a tracked bug for that behaviour in WS, you can take a look at this post
I have explored the problem a bit more, knowing that if I go to WS support, I’m going to be asked to fill out a long formal bug report and provide a reproducible example and blah blah blah. I discovered that in a new meteor helloworld app ie meteor create --full, then I can debug with WS 2018.2.5 perfectly normally. But in my large and old project, this problem happens dependably.
Thinking that possibly the problem is from some old cruft hanging around in caches or configurations, I check out fresh sources a built from scratch, and built a brand new Webstorm project too. No difference. It is interesting that I have almost exactly the same problem in the Chrome debugger.
Chrome debugger breakpoints aren’t working in the app?
I meant connecting to the backend with the chrome://inspect debugger, not client-side debugging. The problems are very similar the chrome inspector, breakpoints that are already set when the debugger connects will sometimes/usually work, but new breakpoints set at runtime never work. And almost always, when trying to step over a fiber function like a database call, it stops stepping and “continues”.
This may not be of interest – and/or may be something you’ve done previously of course – but one way of pursuing this is the equivalent of a binary seek-- duplicate the project folder and:
- Throw out half the code (e.g. most of the front end, or half of the back-end functions, etc).
- See if the anomaly is still present
- If so, throw out half of the remaining code
- Continue until the source of the anomaly is pinpointed or at least until there’s a small demo project to send to IntelliJ support.