I use intellij with a mean stack and i want to debug the js file of my server.
Until now, i launch "grunt serve" in a line command from the directory where my project is and i have no problem.
In intellij there is two way to debug a project with nodejs. You can use the remote debug configuration. This way is working but not very confortable. you have to stop the debugguer each time you made a change in your js files and you have to restart the debugguer....
Or you can configure a GruntJs configuration.
I try to use this way but i don't have the same behavior that i have when i launch "grunt serve" in a terminal from the project directory. The process stuck at the "concurrent:server".
this is my configuration from intellij :
And this is the line command generated by intellij
/usr/bin/node --debug-brk=36118 --expose_debug_as=v8debug /home/bryan/Documents/projects/subscriptions/node_modules/grunt/node_modules/grunt-cli/bin/grunt --gruntfile /home/bryan/Documents/projects/subscriptions/subscriptions/Gruntfile.js -v -d serve
So my question is : What's the difference between using "grunt serve" in a terminal or using a grunt debug configuration from intelliJ ?
Well i found theses links from intelliJ Support
Solution :
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206320279-AngularJS-debug-grunt-server-hangs-at-Running-concurrent-server-concurrent-task
Explanation :
http://stackoverflow.com/questions/19252310/how-to-fork-a-child-process-that-listens-on-a-different-debug-port-than-the-pare
The problem is likely caused by the way Grunt spawns child tasks. By >default, the spawned child process uses the same debug port as a parent >process - as a result the forked process is suspended and the >application 'stalls'. See >http://stackoverflow.com/questions/19252310/how-to-fork-a-child-process->that-listens-on-a-different-debug-port-than-the-pare, for example.
Please try adding process.execArgv = []; at the top of the gruntfile.js
at the top of your Gruntfile.js - does it help?
And yes adding process.execArgv = [] at the top of GruntFile.js remove the stuck of "concurrent:serve" but my breakpoints don't work on port:5858
before overwritting process.execArgv here is content :
[ '--debug-brk=40305', '--expose_debug_as=v8debug' ]
At the start of the "grunt serve" i have this :
/usr/bin/node --debug-brk=40305 --expose_debug_as=v8debug /home/bryan/Documents/projects/subscriptions/node_modules/grunt/node_modules/grunt-cli/bin/grunt --gruntfile /home/bryan/Documents/projects/subscriptions/subscriptions/Gruntfile.js serve
debugger listening on port 40305
Running "serve" task
And at the end :
Running "express:dev" (express) task
Stopping Express server
Starting background Express server
debugger listening on port 5858
Express server listening on 9000, in development mode
In the intellij debugger variables panel its show "Connected to localhost:40305"
When i use a second debug configuration with nodejs debug remote on port :5858 breakpoints are working but this is ugly as i have described in my first question.
i tried this solution but nothings changes :
https://stackoverflow.com/questions/21957411/debugging-grunt-with-intellij?rq=1
my gruntfiles already own theses properties :
express: { dev: { options: { script: 'app/server.js', debug: true } } },
and theses modifications at line 71 in this file node_modules\grunt-express-server\tasks\lib\server.js, changing '--debug' to '--debug-brk='don't affect debugging.
Related
I'm creating a simple REST Server using Vert.x on intelliJ IDEA. When I run to test it, processes never are stopped after clicking the stop button from intelliJ. I undestand this because if I try to run, stop and rerun will appear the error "Address already in use: bind" so each time I must search java processes and kill them by Task Manager. Someone know a better solution?
I resolved changing in my build.gradle.kts this line of code:
tasks.withType<JavaExec> { args = listOf("run", mainVerticleName, "--redeploy=$watchForChange", "--launcher-class=$launcherClassName", "--on-redeploy=$doOnChange")}
With this:
tasks.withType<JavaExec> { args = listOf("run", mainVerticleName, "--launcher-class=$launcherClassName", "--on-redeploy=$doOnChange")}
So I removed the "--redeploy=$watchForChange" and it works fine.
I'm using Visual Studio Code.
I just created a resolvejs application.
How to run the application step by step from vscode ?
Here is my debugging setup (in .vscode\launch.json):
{
"type": "node",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/run.js",
"args": [
"dev"
],
"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/babel-node",
"runtimeArgs": [
"--nolazy",
"--inspect"
]
}
My breakpoints in my command handlers do not work.
Although file run.js is some kind of entry point in resolve framework-based application, it is not actual entry point for runtime phase. When resolve application is being launched by yarn dev / npm run dev command, in fact two actions are performed: building bundle using run.js (which by default uses config.[MODE].js files for appropriate mode) and launching target bundle in separate process with watch mode, which causes automatic rebuild on every file change in project (aka hot reload).
Bundle is stored at <APP_DIR>/dist/common/local-entry/local-entry.js. To allow debugging from IDE, spawned debug nodejs should invoke target bundle directly. It can be reached by separating application compile- and runtime phases.
Resolve includes command for application building without run it - yarn build / npm run build. This command builds application in production mode, but this behavior can be easily modified to development mode by editing run.js entry point - just find line case 'build': and replace following line from await build(merge(baseConfig, prodConfig)) to await build(merge(baseConfig, devConfig)). Or additional script for building app in dev mode can be appended, like yarn build-dev - amount of possible scripts is unlimited.
Then just run command yarn build and start debugger with pointing entry point as ${workspaceFolder}/dist/common/local-entry/local-entry.js. If source maps had built right, breakpoints should work fine.
I run my Protractor tests using a gulp task and I pass all the parameters in the gulp task like:
gulp protractor-integration --useProxy=true --baseUrl=http://10.222.25.18:81 --apiUrl=10.124.22.213:8080 --suite=tests
I have tried to set up a configuration in WebStorm for Gulp and pass all the parameters there. When I hit run the correct tests are executed.
When I put a break point and hit debug the tests are executed and WebStorm does not stop at the break points.
Gulp Configuration in WebStorm for Debugging is not working. Sample Picture
Gulp run configuration is not supposed to be used for protractor tests debugging - it was designed to run/debug Gulp tasks.
To debug certain Node.js application, like Protractor tests, you need to make sure that debug arguments (--debug-brk/inspect-brk) are passed to Node process that starts the application. In your case, the application is spawned as a child process by Gulp. The IDE can only pass debug args to the main process (Gulp), that's why only Gulp tasks themselves will be debugged and not the child processes started by these tasks.
If you still prefer using Gulp to start your tests instead of using the dedicated Protractor run configuration, make sure that protractor process is started with --debug-brk/inspect-brk .
Do do this, you need changing node_modules/gulp-protractor/index.js accordingly. For example, modifying childProcess.fork call as follows will start Protractor with --inspect-brk=5860:
child = childProcess.fork(getProtractorCli(), args, {
stdio: 'inherit',
env: process.env,
execArgv: ['--inspect-brk=5860'] //added line
}).on('exit', function(code) {
...
I am trying to figure out what is wrong with my sessions (using express-session), and I found that it uses the debug module. However, I can't seem to enable the debug messages. It says, debugging needs to be enabled through the DEBUG environment variable, but I can't seem to get it to run.
The tutorial in the README has this picture:
Under Windows I get "DEBUG is not a command for the command-line".
So I tried setting the environment variable explicitly using:
process.env.DEBUG = "*";
and still nothing.
What am I doing wrong?
As Traveling Tech Guy suggested in the comment, in a Windows command prompt, the proper syntax is:
set DEBUG=* & npm start
Obviously you can replace npm start with whatever command you need to launch your Node.js app. Just be sure to use the set command and don't forget the & between that command and the one launching your Node.js app!
If you are used to powershell, I recommend this setup in your package.json, then you can just run npm start so you don't type all that out every time.
"scripts": {
"start": "#powershell $env:DEBUG='*,-express:router*' ; node app.js"
},
Install debug package with npm inside the node application
npm install debug
Open a powershell and then
$Env:DEBUG="name_to_call"
node path_to_js_to_execute.js
Inside your pgm
var debug = require('debug')('name_to_call');
Firstly you need to install the debug module using
"npm install debug --save"
you will see that the following lane has been added to you package.json (which has all the npm modules charged to your proyect)
then you need to add this to import the module to the file in which you want to run the debug
var debug = require('debug')('name_to_call');
now we have to just put the message we want to write, for example hello
var debug = require('debug')('name_to_call');
debug('Hello');
(try pasting the code above directly to a file)
Now we just need to start the windows server with DEBUG, to do so we are going to use the npm package cross-env that will make easier to set an ENV variable across any operating system (platform agnostic)
npm install cross-env
Change the package.json and add the following under the scripts section
"start-server": "cross-env DEBUG=name_to_call node server.js"
Now to start the server just run the following in a command line (from the directory in which your project is) and you are good to go
npm run start-server
In Babun a windows shell, I run,
npm
npm install debug --save
babun
DEBUG=http node app
app.js
var app = express();
var debug = require('debug')('http');
var http = require('http').Server(app);
var server = http.listen(app.get('port'), function() {
debug('listening on port ' + server.address().port);
});
works like a charme for me.
Windows Command:
set DEBUG=* & node ./app.js
PowerShell:
$env:DEBUG='*'; node app.js
Terminal/WSL (Ubuntu):
DEBUG=* node ./app.js
I am running jasmine tests on Karma server.
On my tests I have to load a image and a json file test.
They depend on path. Which is the default path for Karma? I mean if i have a image in a directory inside my .js test files how can I reach that file?
I have tested src="myDir/myImage.jpg" but no sucess...
If you use a nodejs web-server to run your app, you can add this to karma.conf.js :
proxies: {
'/path/to/img/': 'http://localhost:8000/path/to/img/'
},
If you don't use or want to use another server you can define a local proxy but as Karma doesn't provide access to port in use, dynamically, if karma starts on another port than 9876 (default), you will still get a 404 error...
proxies = {
'/images': 'http://localhost:9876/base/images'
};
Based on this answer
Related GitHub issue for more info ;)
I would also suggest using requireJS because Karma does not deal well with fixtures...
proxies = {
'/images': 'http://localhost:9876/base/images'
};
To avoid 404 error if karma starts in in a different port, even after setting proxies, do the following:
Kill all the process using the port starting from 9876 (killing node.exe will do the trick)
Run you karma with 9876 port free now
Subsequent runs will be mapped automatically by karma to whatever port it launches