Meteor 1.6 Always Stopping at debug.js (debugger;)

Node.js debugger always stops on debugger; statements - see https://nodejs.org/api/debugger.html - it's a core feature that can't be bypassed on client side. You have to comment out this line if you like to have this breakpoint skipped

Thank you,  that was the first thing I tried, but for a Meteor application was not working.. I managed to solve the problem a different way. I returned back to Webstorm 2017.2.5.

All I did was run two configurations, one is  ran like normal using a Meteor configuration, with the javascript debugger checked and the program arguments added:

--inspect --settings settings.json

Next I created another configuration, this time Chromium remote, and set it to port 9229.

I just run both and make sure the debug Async option is checked, can now use the debugger again as before on server and client :)

Hi,

Alvaraj2 - thanks for raising this issue and thank you Elena for your comments.

Does anyone have a deeper understanding of this?  Is it something Meteor 1.6 has added or is it the result of a change to WebStorm 2017.3 debugging setup?  Alvaraj2 isn't kidding when he says "to a crawl".

The file shown above is built (by Meteor's build system, I think) on every 'hot reload', so it doesn't help to comment out the debugger line.

I prefer to keep WebStorm up to date, so rolling back to 2017.2.5 isn't an option for me.

Cheers,

Steve

The file is auto-generated by Meteor and is supposed to be used for debugging. See https://docs.meteor.com/commandline.html#meteordebug: when being run with debug, server process is suspended just before the first statement of server code that would normally execute. For this purpose, the debug.js file with debugger; statement is generated - just as it's written in this file:

// The debugger pauses here when you run `meteor debug`, so that you can
  // set breakpoints or add `debugger` statements to your server code
  // before the code begins executing.

There is no way to avoid suspending debugger on this statement - since Node.js 4, Node process always suspends on these statements even if no debuggers are attached, so this is not something that can be solved on IDE side, it's a core Node.js feature

Thanks for looking into this, Elena.

I'm still not sure about one thing: do you think this is something that changed very recently in Meteor?  I ask because I didn't see this behavior in WebStorm 2017.2.5.  It appeared when I updated to WebStorm 2017.3.  But I also updated to Meteor 1.6 at the same time.  

So you think Meteor 1.6 changed rather than WebStorm's debugging?

Stopping at debugger; statement is not something that can be affected by WebStorm upgrade - as I wrote, it's a core Node.js feature. But I can't tell for sure if this `debug.js` generation was introduced in Meteor 1.6 - didn't find any info regarding this

I tracked down the source file (on Windows 10) to

C:\Users\eskopal\AppData\Local\.meteor\packages\meteor-tool\1.6.0\mt-os.windows.x86_64\tools\static-assets\server\debug.js

change eskopal to your user name.

I tried commented out the debugging statement. That didn't work.  It hung for 5 minutes then announced that the debugger didn't attach -- and it was starting anyway.

I ended up duplicating my normal "Configuration" and adding "--inspect" to the program arguments.  Then "Run" instead of "Debug".  No startup pause, and I can connect in the Terminal window using Meter Shell.  If I need breakpoints, I use "Debug".

..Eugene..

The whole reason for my purchase of WebStorm was for its Meteor debugging functionality. This functionality has basically been broke since Meteor 1.6 came out. 

IMHO, someone involved in WebStorm's Meteor tooling should try to get to the bottom of this, working with the Meteor team if need be.

I'm very frustrated.

Thanks, Chuck, for making your feelings known to JetBrains.

In the short term, the simple workaround I just confirmed is to use the two Run... items from the Run menu rather than the two Debug... items.  Then, if the configuration has the 'with JavaScript debugger' option ticked, client-side breakpoints will still work.  Server breakpoints won't work, but the annoying debugger statement will be avoided on hot reload.

When I need server debugging, I'll use the two Debug... menu items and temporarily suffer the annoying debugger statement.

Chuck, maybe that workflow will reduce your frustration a fraction, for the short term.

 The issue is caused by Webstorms MeteorJS plugin inserting --inspect-brk in to the application path when you run the debugger. 
This forces it to break before the code starts.  
--inspect performs the same action - but does not force the break. 

I tried adding just --inspect to the Program arguments  but Webstorm MeteorJS plugin overrides it 

My Program arguments in Meteor Debug Config : --port 3001 --inspect --settings ../config/development/settings.json

Webstorm rewrites this as (viewed in the applicatoin debug console): /usr/local/bin/meteor --inspect-brk=39053 --port 3001 --inspect --settings ../config/development/settings.json
Both --inspect and --inspect-brk provided; ignoring --inspect.

Here is are the params identified in Node Inspector 
https://nodejs.org/en/docs/inspector/

The issue lies in : 
Meteor-173.3727.69\Meteor\lib\Meteor\com\jetbrains\plugins\meteor\runner\MeteorRunProfileState.class

Line 6

please see https://youtrack.jetbrains.com/issue/WEB-30124#comment=27-2591411

Esther - impressive bit of sleuthing.  Thank you for sharing your findings, and in such a way that JetBrains can do something about it.  Bravo.

Ah, and I see that, like always, Elena is right on top of things.  Thank you both.

Yes - thanks Elena.  Always very fast to reply with useful answers !

This problem is actually worse than I first thought. Others have probably already noticed as well. 

It used to be that my coding changes didn't get activated until I clicked on my Chrome window. Now, as soon as I start typing, the changes get activated and WebStorm swaps out the active window to the dreaded debug.js window so that I can uselessly press the continue button. Then I go back to the file that I was editing, continue making my changes, only to have the same thing repeated. 

Regardless of whether this should be considered "a feature" or a bug, the user experience has regressed and the current design is badly flawed. I hope someone is working on a fix.

Meteor shouldn't normally be restarted on typing. Please make sure to disable Live edit (Settings | Build, Execution, Deployment | Debugger | Live Edit, Update application in Chrome) to avoid auto-saving on changing a file

First, previous to my upgrade to WebStorm, I had "Update application in Chrome" set and chrome was not updated until I clicked on the Chrome window. Was there a known update to WebStorm that accounts for this change in behavior?

Second, if I am using Chrome and the "JetBrains IDE Support" extension, don't I want to have "Update application in Chrome" set? Perhaps I just don't really understand this option. Can you explain a bit?

>previous to my upgrade to WebStorm, I had "Update application in Chrome" set and chrome was not updated until I clicked on the Chrome window

This option was introduced in 2017.3, so you didn't have it set before upgrade:)

>Second, if I am using Chrome and the "JetBrains IDE Support" extension, don't I want to have "Update application in Chrome" set? 

yes - this option enables both Live Edit and Chrome extension; it's not possible to debug with extension if Live edit is disabled

I wasn't aware of that particular setting. After you mentioned it, I looked in my preferences, and it was checked. So, not knowing any better, I assumed that it was checked before the upgrade. I do know that prior to the upgrade that I had "live update" enabled. So, Live Update isn't new, but it's design has been augmented and modified.

I do know, however, that prior to the upgrade, my edits were not activated in Chrome until I clicked on my Chrome window.

The changed behavior of "Live Edit" together with the constant need to needlessly press the continue button has severely impacted Meteor debug usability. 

Is there any plan to address this problem in the near future?

Live Edit behavior hasn't changed - it always auto-saves files to provide live reload. Disabling it is the only way to go:(
Please follow https://youtrack.jetbrains.com/issue/WEB-7093 for updates

The Live Edit behavior has definitely changed for me. It used to work like this.... As long as I stayed in WebStorm, builds were not triggered and nothing was pushed to Chrome. Builds and pushes to Chrome were only triggered when I clicked on the Chrome browser window. 

Since no answer has been given to whether there are plans to address this issue, I've temporarily switched over to Visual Studio Code. For anyone else needing to do the same, Meteor setup instructions can be found at https://forums.meteor.com/t/meteor-1-6-server-debugging-with-vs-code/39821