`node --debug` and `node --debug-brk` are invalid. Please use `node --inspect` or `node --inspect-brk` instead

All of a sudden I'm getting this when start debug on my mocha tests, why is that?

WebStorm 2017.2 EAP
Build #WS-172.2953.12, built on June 14, 2017
WebStorm EAP User
Expiration date: July 14, 2017
JRE: 1.8.0_152-release-915-b3 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.6

 

I've been running this setup forever, why would this just bomb out like that during debug in Webstorm?

 

Also when I try running the new code coverage tool, I get this:

 

2
49 comments

seems the Node.js version babel-node is using doesn't accept `--debug-brk` option, and Webstorm can't detect what Node.js version is being used.

Normally webStorm uses `--debug-brk` for Node < 7.x and `--inspect`/`--inspect-brk` for Node.js 7/8.

Debugging with babel-node is not supported (as we have already discussed); please use a normal Node.js interpreter and pass `--compilers js:babel-core/register` to Mocha (as you do) - do the issues persist?.

0

yea thanks I can't remember which way is up anymore.  So babel-node is now legacy right?  Basically that stuff is now built into node or something?

 

yes that works, going that route.  I just forgot to change it back to using node not node-babel when I was trying that route.

0

>So babel-node is now legacy right?  Basically that stuff is now built into node or something?

not yet - modules are still not supported natively, AFAIK:( But passing `--compilers js:babel-core/register` should be enough to get code transpiled. And babel-node is not supported for debugging as it doesn't allow exposing v8 (necessary for debugging with v8 protocol)

0

I am also having this issue but my setup is a little custom. I have a custom build of NodeJS 7.4 which only works with the old --debug-brk. Up until now if Webstorm could not determine the version it used the old --debug-brk but now its using the --insert-brk by default and I am getting:

Inspector support is not available with this Node.js build
Luna: bad option: --inspect-brk=51079

Is there anyway i can make it use the old --debug-brk

Thanks

1

Try disabling js.debugger.node.use.inspect Registry option (help | Find action, type 'registry' to open it) - does it help?

1

Hi. 

I'm using Webstorm to code in meteor.
Even if my meteor version is frozen in release 1.3.3.1 (I launch it with the --release parameter), the core was updated in meteor 1.6 who use node.js 8. So my webstorm is telling me "--debug-brk=33014 is not allowed in NODE_OPTIONS"

The problem is, I can't use --inspect parameter instead of --debug-brk. How can I proceed ? 

Thx for advices.

1

Thx for your answer Elena,

I tried it, and got the same error message, and still can't force the --inspect instead of --debug-brk :/

0

what meteor version is specified in .meteor/release?

0

I got a frost version so I got "METEOR@1.4.1.1" in the release file.

But when I launch my apps (with /usr/local/bin/meteor --release 1.3.3.1 in debug via webstorm), here is the full error message : 

home/foo/.meteor/packages/meteor-tool/.1.6.0.dnzrut++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/node: --debug-brk=43550 is not allowed in NODE_OPTIONS

As you can see, it seems to be using 1.6 stuffs even if i'm downgrading the version.

Anyway, thanks for your interest in my problem.

0

Thanks, reproduced. Logged as https://youtrack.jetbrains.com/issue/WEB-29676

The problem occurs because WebStorm uses version specified in .meteor/release instead of meteor --version to detect current Meteor version, and sets the debug options accordingly

0

Is there a possible way to continue to debug in webstorm with a quick fix on my version ? 

I innocently tried to cheat by changing it in the release file (put "METEOR@1.6"), I can now launch my application in debug mode without a problem, but the breakpoints don't catch where they should :)

0

Debugging works for me... Can you recreate the issue using one of Meteor sample projects?

0

I tried before and I just redone the job with an new instance of meteor. My debugger is turning around and the page never show up.

What I have done :

- meteor create NewHelloWorld
- Launching the Webstorm2017.3
- Opening the new project
- Edit Configuration and add the Meteor

When I simply launch the helloworld project, there is no problem.
When I click the debug, my chrome's page is waiting infinitly the meteor's responses !

The week-end will maybe help me us :)

0

Please can you provide a screenshot with meteor run console, so that I can see the full command WebStorm uses when launching the debugger? I suspect that the issue may be related to wrong flags (--debug --debug-port) being used instead of expected --inspect-brk...

0

I dunno what I have done, but it works for debugging client side ! 

I reinstalled webstorm 2017.3 and this time it asked me to convert my project. I said yes and after using the debug mode, I can finally put breakpoint in client side. But it still doesn't catch my breakpoint in server side.

If it can help you, here is the log

/usr/local/bin/meteor debug --debug-port=41677 --release 1.3.3.1
=> Using Meteor 1.3.3.1 as requested (overriding Meteor 1.6)

[[[[[
~/Documents/projects/garandeau/hs6_new/intranet/WebstormProjects/IT7_MeteorPrinting
]]]]]

=> Started proxy.

Changes to your project's package version selections:

accounts-base downgraded from 1.2.11 to 1.2.8
accounts-password downgraded from 1.3.0 to 1.1.11
[....]
webapp downgraded from 1.3.11 to 1.2.9


Your application is now paused and ready for debugging!

To debug the server process using a graphical debugging interface,
visit this URL in your web browser:
http://localhost:43899/debug?port=41677

=> Started your app.

0

`debug --debug-port` is the culprit... Please try upgrading to the most recent EAP (173.3622), it must be fixed there

0

It sound like I'm stucked with my frost meteor version ! 

The new EAP is working when I don't use the --release argument. 
The problem is : I can't use this meteor version and need to use the 1.3.3.1

But If I used the would like version, here is what I got :


It's pretty weird ! Node don't understand anymore the --debug-brk if I'm using an older version, but if I use an older version, it's still don't understand his new --inspect-brk argument... !

0

Indeed, node 8 8.1 bundled with 1.6 doesn't support --debug-brk, and meteor 1.3.3.1 knows nothing about --inspect-brk - it was introduced in @1.6

0
Avatar
Alexey Zerkalenkov

After update to WebStorm 2017.3 I have the same problem with Luna / Node 7.4.0:
`Luna: bad option: --inspect-brk=50228`
I've inspected registry in there is no option js.debugger.node.use.inspect there.
How can I disable inspector in the new version?

0

There is no such option, `--inspect-brk` is now always used for debugging Node.js 7+ apps

-1
Avatar
Alexey Zerkalenkov

There is no inspector support in Node 7.4.0. When I try to debug Luna application in WebStorm 2017.3 I get an error:
Inspector support is not available with this Node.js build
.../Luna: bad option: --inspect-brk=55647
It worked with `--debug-brk`in 2017.2 when I unchecked that option. I have no possibility to update Node as well.
How can I proceed?

0

Indeed, `--inspect-brk` was introduced in Node.js 7.6.0. But, as I have just checked, WebStorm doesn't use it when starting Node.js 7.4.0 app, it starts "C:\Program Files\nodejs\node.exe" --inspect=41696 --debug-brk app.js"

What does you run configuration look like? Seems WebStorm can't correctly detect the interpreter version

0
Avatar
Alexey Zerkalenkov

We run Luna which is a custom node interpreter based on Node 7.4.0:



This is not system wide registered NodeJS interpreter. Also when I use `nvm` and point system to use Node 7.4.0, it does not help as well.

0

Debug options being passed depend on interpreter version. It can only be detected if the Node.js interpreter (and not a custom script/app) is chosen in Node.js run configuration. When using Luna as interpreter, WebStorm fails to determine the interpreter version and uses default options. This can hardly be fixed, sorry

0
Avatar
Alexey Zerkalenkov

Exactly! This is the problem I'm talking about. In the previous version (2017.2) there was a registry flag, which forced WebStorm use an old debug option, now it is gone. Why?! Why you rely only on automatic detection and disable manual override for devs like we?

> WebStorm fails to determine the interpreter version and uses default options. This can hardly be fixed
Is it too hard to make an option for manual override? Just one checkbox which disables any options on node start. Luna fails because of invalid option. I can define `--debug` flag  in the debug config.

0
Avatar
Alexey Zerkalenkov

Great! Thank you!

0

In 2017.3, the 'node.js' run configuration default setting was removed which broke my debugging capabilities. Now there's only 'npm' as a run config option which doesn't allow me to point an interpreter at a javascript file.

For me the problem is definitely 2017.3 & I've downgraded back to 2017.2

I can debug again by pointing a 'node.js' run config to the babel-node interpreter with --inspect in the node params window and pointing to my ES2015 node app as the javascript file, like so:


Intellij: this option will continue to be useful for debugging ES2015 server side apps until babel-node is completely redundant. Please can you put it back?!

 

0

Please sign in to leave a comment.