node inspector with mocha not working with 'debugger' command - node.js

I am using mocha to test my code. I am using node inspector to debug my code.
bash
mocha test/test.* --debug-brk
This works but not so well. It stops at the first line of code in mocha. I want it to stop it at my code. I tried using the 'debugger' key word to make a manual breakpoint but some how it does not stop there.

Try placing a breakpoint at the bottom of the mocha library per this issue. For some reason that allows debugger statements in your modules to pause the node debugger.
However it doesn't seem to stop at debugger statements in the spec itself. I have a SO question highlighting that problem.

I was on the latest node version, using the node-debug command (to launch node-inspector and having the same issues you were. Here's what I'm rolling with currently:
Using the following versions:
node: 0.11.13 (I downgraded from latest) <-- I specifically had to use this one
mocha: 2.2.1 <-- might work with any
node-inspector: 0.9.2 <-- might work with any
Start your tests using the following command:
node-debug _mocha test/unit-tests.js
Navigate to your test file and start putting in breakpoints, then hit run. I usually put one up by the 'requires' of my test file, and several within my 'it' functions.
Hope that helps, and that one day this kind of thing will just work :P
Got the idea to downgrade node from here:
https://www.bountysource.com/issues/7978672-script-is-resumed-as-soon-as-node-inspector-is-loaded
And the command from here:
https://github.com/node-inspector/node-inspector#how-do-i-debug-mocha-unit-tests

Related

WebStorm + nvm + Typescript + ts-node + Breakpoint Debugging - Randomly Stops Working

I have an issue with WebStorm that I can't seem to figure out and JetBrains hasn't been much help either.
It appears to sometimes show up, sometimes go away, and just flat out make zero sense. Debugging breakpoints in WebStorm will flat out stop working if they're inside of a non spec file function.
I'm using mocha, and my setup is as follows:
nvm - using node 14.16.1
mocha 9.02
User interface: BDD
Env. Variables:
NODE_ENV=development;TS_NODE_FILES=true;TS_NODE_TRANSPILE_ONLY=true;TS_NODE_PROJECT=tsconfig.tests.json
Extra Mocha Options:
--require ts-node/register
Test file patterns:
src/tests/unit/**/*.ts
JetBrains had thought it was my code base, however, if I were to take and setup my other laptop with it, it breakpoints and works fine. However with WebStorm it randomly stops allowing me to breakpoint debug into nested functions...
I've tried uninstalling the nvm node version and reinstalling, wiped out node_modules and reinstalling, tried installing different node version and rebuilding node_modules. Nothing seems to resolve it.
One interesting piece, breakpoints work as expected when I don't run Spec files and run the app normally.

LESS #plugin Debugging (node)

Does anyone know how to debug a less plugin when using node to compile? So that I would be able to see the value of console.log() within custom less functions.
I am also using gulp-less. I have tried to run the gulp this way:
node --inspect --debug-brk /usr/local/bin/gulp compilecss
This ran the gulp task but I don't see any console from within the function inside the javascript #plugin.
The above mentioned method worked, the issue was that the plugin wasn't set up correctly. For those who were in my shoes this is what worked:
Follow the instructions on this answer for getting the inspector in the gulp task.
enter link description here
Then if your plugin is installed you should see logs in the console from the less custom plugin or it's functions.

Debugging Serverless Framework invoke local function

I am trying to debug sls invoke local.
My setup:
However I keep getting:
/Users/nikos/.nvm/versions/node/v6.9.1/bin/node --debug-brk=63417 --expose_debug_as=v8debug /Users/nikos/.nvm/versions/node/v6.9.1/bin/serverless invoke local -f createTodo
Debugger listening on [::]:63417
Process finished with exit code 130 (interrupted by signal 2: SIGINT)
OK, I've figured out how to do this with real Chrome Devtools with the excellent node --inspect. This is much better than node inspector because it uses the latest built in chrome devtools. (more info on node inspect)
node --debug-brk --inspect $(which serverless) invoke local -f myfunctionname
I ran that but my function wasn't loaded yet (probably some lazy loading in the serverless code). So I added a debugger to the top line of my function and everything seems to be working great.
In my case I also needed some test data, so I passed that through like this.
node --debug-brk --inspect $(which serverless) invoke local -f postprocess -d '{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"us-east-1","eventTime":"2017-06-17T05:08:29.598Z","eventName":"ObjectCreated:Put","userIdentity":{"principalId":"ALS78N87ZDYNW"},"requestParameters":{"sourceIPAddress":"52.119.114.78"},"responseElements":{"x-amz-request-id":"2EB4FAD5892EC247","x-amz-id-2":"nVLasIYsWvWm7xwONiTB6z7L8oXKkvPOb9FntOYoG/kKS+PuWwbMJ1xM7n/C1X3NJh5FUCj4aEM="},"s3":{"s3SchemaVersion":"1.0","configurationId":"3c3b2a71-b639-4116-b246-08dcacd0c7d6","bucket":{"name":"simmer-uploads-test","ownerIdentity":{"principalId":"ALS78N87ZDYNW"},"arn":"arn:aws:s3:::simmer-uploads-test"},"object":{"key":"example+%285%29.zip","size":4757597,"eTag":"9aa90579ee4e8152e6dfa60258754a83","sequencer":"005944B94AD9307261"}}}]}'
I am working on a Mac, and I heard there might be some problems with $(which serverless) on windows. But someone give it a shot and let me know.
I was able to setup my PHPStorm debugger configuration in a way that now I can step through my functions locally (using serverless-offline plugin).
I am triggering functions via http requests using Postman.
See below steps to achieve this:
1.
2.
3.
4.
I've gotten this to work in IntelliJ, so it should work in Webstorm too. You will need the serverless-offline plugin (https://github.com/dherault/serverless-offline)
In your Run Configuration, change your Application parameters to:
offline -s dev
and add the environment variable SLS_DEBUG=*
serverless-offline will start a server that the IntelliJ Node debugger can hook into.
Use this, it emulates lambda and serverless:
https://github.com/dherault/serverless-offline#debug-process

How do you set a breakpoint with node.js jasmine?

Ok, naive question here, but I am somewhat new to nodejs. I am writing a test script using jasmine. There seems to be a bug in my code, so I put "debugger" in one of the lines and jasmine is not stopping for some reason. I know it's getting to the code too, because I put a console.print command and it displays that line.
Is there something incredibly simple that I'm missing? Can't I set a breakpoint in the javascript code and get into a REPL somehow?
You probably run your Jasmine Tests like this:
$ jasmine myTest.js
Or like this:
$ ./node_modules/jasmine/bin/jasmine.js myTest.js
If you want to test node application you have many options, and as you know, jasmine is nodejs code, so you can run it in debug mode, and will run your test, so if you have debugger; in your code it will stop there.
Here are 3 simple ways to debug nodejs applications. Node.js Debug Options
You can use the first one, the build in debugger in nodejs.
Run this command:
$ node debug jasmine myTest.js
Or
$ node debug ./node_modules/jasmine/bin/jasmine.js myTest.js
Then you can press C button + Enter to continue to your debugger; brackpoint in your code...

Node.JS, CLI with VSCode not finding path to NPM modules, launch.json

I want to write a command line program to use via node.js and CLI module. VSCode is not finding .require('cli') so no intellisense.
Then when I launch for debug it isn't looking in the right place, it's looking at APP\npm_modules\cli.js when it is APP\npm_modules\cli\cli.js.
I do have cli installed both locally and globally and I have a NODE_PATH environment pointing accordingly.
The same code works correctly when run at the command line, so it's a VSCode issue. Perhaps, there is a different editor that offers debugging that I should consider?
My mistake. Turns out that I had enabled the debugger to break on all exceptions and as .require resolves, it is looking in several places, eventually the module is found, but there are a number of caught exceptions along the way. I was stuck at looking at the first exception.

Resources