I wrote the following code using 'readline-sync' dependency.
var readlineSync = require('readline-sync');
function main() {
printMenu();
var userName = readlineSync.question('Please enter your choice:');
console.log(userName);
}
main();
I ran this code from WebStorm trying to use the WebStorm console window.
I got the error:
Error: The current environment doesn't support interactive reading
from TTY. stty: when specifying an output style, modes may not be set
When I run it from linux terminal the code works with no error. I understand from the error message that 'readline-sync' cannot work from WebStorm console. Do you have any idea how to solve it?
I found out the answer.
type in WebStorm terminal:
$ node --debug-brk
Web storm will give you the port number the debugger is listening to. On my machine it was 5858. Then press 'Ctrl+C'.
Create a new debugging configuration as the following one:
In WebStorm terminal type again: "$ node --debug-brk main.js "
put a breakpoint somewhere.
Click the debugging icon
Happy Debugging!
Related
When I try to use debugger in node to open debugger, I get an error 'Timeout (2000) waiting for 127.0.0.1:9229 to be free'. How can I resolve this and run the debugger correctly ?
function foo() {
var a = 5;
debugger
console.log(a)
}
foo()
I have already tried changing the port using node inspect --port=9230 app.js and it doesn't work.
Try this:
node --inspect-brk app.js
replace app.js with your file name that you want to run, and you can insert your additional command alongside with this line.
I had the same problem, it took me hours to figure it out...
Run the following command:
node inspect --port=9228 file.js
I had the same issue by using VS Code. VS code document helps. Replace program.js with your js file name.
https://code.visualstudio.com/docs/nodejs/nodejs-debugging
if the program should not start running but must wait for the debugger to attach:
node --inspect-brk program.js
Use node --inspect-brk {js file name} instead. It will work.
--inspect-brk=[host:port]
Enable inspector agent
2.Bind to address or hostname host (default:127.0.0.1)
3.Listen on port port (default: 9229)
4.Break before user code starts
I think the issue here is the command you give to node, it should be node --inspect..
You are missing the -- in front of inspect :)
Install
npm install --global node-inspect
Then
node-inspect script.js
Ref: https://www.npmjs.com/package/node-inspect
My app is a node.js app which I can run through command line using: npm test inside the working directory. In WebStorm, I created a new configuration that looks like this:
Node interpreter: /usr/local/bin/npm
Node parameters: test
Working directory ~/dev/project
When I hit the run button, I get the correct output:
/usr/loca/bin/npm test
> app#1.0.0 test ~/dev/project
something else
Process finished with exit code 0
But since I have breakpoints set, it should have stopped on a breakpoint instead of getting to the Process finished part. I set my code to be pretty simple just so I can test breakpoints, so it looks like this:
"use strict";
let foo = false; (breakpoint)
let bar = true;
if (foo === bar) { (breakpoint)
console.log('something');
} else {
console.log('something else'); (breakpoint)
}
process.exit(1);
I also tried to make this work through command line. In my site settings, I set my Built-in server to port 12345. Can accept external connections, and allow unsigned requests.
when I run it through command line, I use:
npm --debug-brk=12345 test
I get the same result: it runs all the way to the exit point without stopping on the breakpoints.
Any ideas what I need to do to get this to work?
/usr/local/bin/npm is definitely not a Node interpreter, it's NPM package manager that is a Node.js application itself (i.e. it's run with Node.js interpreter). And test is a name of npm script, not a Node.js parameter.
If you like to debug your .js file that is run via npm test, you need to modify your npm script to include the debug options and then use NPM run configuration for debugging. Or, just create a Node.js configuration, set a valid path to Node.js execuitable there (/usr/bin/node or whatever it looks like on your system), then specify your .js file as JavaScript file:. See https://blog.jetbrains.com/webstorm/2017/09/debugging-node-js-apps-in-webstorm for more info
I have added the configuration in the launch.json file with the following details :
{
"name": "Attach"
"type": "node",
// TCP/IP address. Default is "localhost".
"address": "localhost",
// Port to attach to.
"port": 5858
}
Now I start my app with the following command : node --debug-brk ./bin/www
When i go to VSCode and select Attach in the debugging menu on the top and click on the play button.
It attaches, but when i go to browser and open a page, it doesn't it the breakpoint or the handler function in my index.js file.
Can you please help what could be going wrong?
There are two issues with breakpoints in node (and these issues are not specific to VSCode but you can see them in node-inspector as well):
If you set breakpoints in your app's startup code and launch node with --debug (opposed to --debug-brk), node starts immediately and has executed your startup code before VSCode had a chance to register the breakpoints. So if you need to debug startup code use the --debug-brk flag because it allows VSCode to set breakpoints before node starts the application.
Node does not parse source files completely on load but delays parsing of closures (callbacks etc.) until their code is first hit. As a consequence breakpoints set on callbacks are not always correctly registered by node, because it does not have parsed the code yet. This 'lazy' behaviour can be disabled by starting node with the --nolazy flag.
In the next version of VSCode (0.4.0) we try to address these problem as follows:
VScode will always launch node with the --debug-brk flag but will hide the first stop and continue if the user did not specify "stopOnEntry: true". This will avoid problems with missed breakpoints in startup code.
If breakpoints are set in code that has not been parsed by node, node will register them at the next possible position in parsed code. Since these "actual" positions are returned by node to the client, VSCode is able to show these positions. So the user will see that a breakpoint set in an unparsed callback "jumps" to a position further down and he will better understand why the debugger is not stopping at the location requested. In addition we added a "Reapply" button to the breakpoint view which makes it really easy to clear and set all breakpoints.
Your breakpoints are probably set too early and are not registered by node. It should help if you set the breakpoints after you have attached.
We have improved this experience in VSCode and it should be available in 0.4.0
Always clear your breakpoints and set them after you attach. I learned the hard way. This is certainly a bug.
I've been digging into this and here is what I have found so far for 0.3.0.
This does not work!
In Code add a breakpoint to app.js or a route
In terminal run node --debug src/server/app.js
In Code attach the debugger
This works!
In terminal run node --debug src/server/app.js
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This does not work, as --debug doesn't kick in unless its the arg after node and before the file
In terminal run node src/server/app.js --debug
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This works, assuming you have a gulp process
In terminal run gulp serve-dev --debug
In Code remove all breakpoints
In Code add a breakpoint to app.js or a route
In Code attach the debugger
This does not work, sometimes
In terminal run gulp serve-dev --debug
In Code add a breakpoint to app.js or a route
In Code attach the debugger
Why sometimes? The best I can tell is that that the breakpoints sometimes get funky. Sometimes they work fine, and other times I have to remove them and re-add them before attaching the debugger.
When I try to set a breakpoint and debug the file, the debugger just run the app without stopping at breakpoints.
This is my code:
console.log('123');
And this is my output:
/usr/bin/node --debug-brk=39765 --nolazy index.js
debugger listening on port 39765
123
Process finished with exit code 0
Does anyone has an idea what could be the problem?
Try to disable js.debugger.v8.use.any.breakpoint in WebStorm registry.
You can do it by going to Help -> Find Action
In there just enter Registry.
For me disabling this option made debugging anything node-related much faster and much more predictable.
Wanted to chime in and say that it is absolutely critical that you use --debug-brk and not --debug with getting WebStorm breakpoints to work for remote debugging as well as running the server directly from webstorm.
Even though --debug-brk technically just stops and waits for the debugger to join, and --debug allows you to join later, my breakpoints failed with just --debug no matter the remote configuration I tried.
As far as I can tell, connecting WebStorm 11 to a node.js server on the debug port, with only --debug, will connect but fail to load any breakpoints that work.
disabling js.debugger.use.node.options in the webstorm registry helped me
https://youtrack.jetbrains.com/issue/WEB-47774#focus=Comments-27-4436526.0-0
Debug breakpoints not work in my PhpStorm 2016.3.2 with NodeJS 7.7.x. My expectation is, that WebStorm will have same issue.
If you downgrade to Node 6 (I tested with 6.9.4), it starts working correctly.
For me the issue was that WebStorm didn't play well with my typescripts. It would say debugger listening and then run through the entire program without stopping at the breakpoint as described in the question.
The workaround I used was to simply put the breakpoint in compiled js file and debug from there instead.
Go to Run -> View Breakpoints... or hit
shift+command+F8 in OS X.
Select your breakpoint from the list and make sure Suspend is checked.
Fixed the issue by enabling generation of 'map' file in the TypeScript configuration.
Add '--sourceMap' in Tools-->Languages & Frameworks-->TypeScript-->Options
I'm having the same issue in version 2022.2 but I don't think it is a problem with the version
Here are the potential solutions;
Go to;
WebStorm -> Preference -> Build, Execution, Deployment -> Debugger
Click "Allow unsigned requests" checkbox and make it checked
This solved my issue.
Or
Check your local environment. What I mean by saying check your local environment is usually more than one service is trying to use the same debugger port if we speak about the e.g. nodejs.
You will get the following message if you try to run two services at the same time in the debug mode;
Starting inspector on 127.0.0.1:9229 failed: address already in use
Try to start the main service first that you try to debug.
I am trying to debug the child_process example from here using IntelliJ IDEA 12.1.3 and node 10.10. When I run nodejs app.js from a terminal everything works. The console output displays as expected. However, when I debug the same script using IDEA there are no messages in console output and the app just sits there. This is what is in the console window:
/usr/bin/nodejs --debug-brk=58954 app.js
debugger listening on port 58954
debugger listening on port 58954
When I run the script in IDEA without the debugger attached, the script works as expected.
Why does attaching the debugger break the script?
You can force the children to use a free port for debugging. InteliJ will automatically pick up the port chosen by the child process.
Here's an example:
// Determine if in debug mode.
// If so, pass in a debug-brk option manually, without specifying port.
var startOpts = {};
var isInDebugMode = typeof v8debug === 'object';
if(isInDebugMode) {
startOpts = {execArgv: ['--debug-brk']};
}
child_process.fork('./some_module.js', startArgs, startOpts);
looks like a bug in node.js fork to me: both parent and child processes receive --debug-brk=58954 switch and attempt to start debugger and listen port 58954.