I am using Electron (front-end) and Node.js (Sails back-end). Both are in TypeScript(ES6).
I want to debug Sails application controller.
I selected some break points in the application (back-end) using WebStorm.
Gulp run configuration is not supposed to be used for Node application debugging - it was designed to run/debug Gulp tasks. To debug your Node.js application, you need to create a Node.js Run configuration (see http://www.sullivansoftdev.com/blog/2014/04/12/debugging-sails-applications-with-webstorm/ for some hints)
If you still prefer using Gulp to start your server, make sure that server process is started with --debug-brk (for Node version <= 6.x) or --inspect-brk and then use either Node.js Remote (Node <= 6.x) or Chromium Remote (Node.6.x) run configuration to attach the debugger.
Like:
var gulp = require('gulp');
var exec = require('child_process').exec;
gulp.task('server', function (cb) {
exec('node --debug-brk=5858 app.js', function (err, stdout, stderr) {
...
run your server task, then select Node.js Remote/Chromium Remote run configuration and hit Debug
Related
I have inherited a project running gulp+nodejs. I am trying to use IntelliJ in Windows as my IDE.
If I set my runtime configuration to use "node.js" as its type, I have no problem hitting breakpoints and debugging. However, if I use "gulp.js" as the run type, breakpoints are ignored (and I can essentially never debug). I also tried using Node.js configuration and setting the JS file to node_modules/gulp/bin/gulp.js instead of server/run.js . This seems to have the exact same problem.
Any thoughts on how I could fix this?
Gulp run configuration is not supposed to be used for Node application debugging - it was designed to run/debug Gulp tasks. To debug your Node.js application, you need to create a Node.js Run configuration and specify the .js file generated by Gulp build as a file to debug.
If you still prefer using Gulp to start your server, make sure that it is started with -debug-brk and then use Node.js Remote run configuration to attach the debugger.
Like:
var gulp = require('gulp');
var exec = require('child_process').exec;
gulp.task('server', function (cb) {
exec('node --debug-brk=5858 app.js', function (err, stdout, stderr) {
...
run your server task, then create Node.js Remote run configuration and hit Debug
Im using GitHub Electron to create Desktop application with web technologies.
I'm using Node.js as the server, my problem is that i don't know how to run the file server.js just when launching the electron app.
I want to package my app for distribution so that i can run the server without the command line $ node server.js.
Just simply require the server.js file in your main file (e.g. app.js):
var app = require("app")
, server = require("./server")
;
...
And in the server.js file you can have:
require("http").createServer(function (req, res) {
res.end("Hello from server started by Electron app!");
}).listen(9000)
I'm confused. So if I use gulp-develop-server, it's got a app.listen():
gulpfile.js
config.server.path is set to './app,js'
server = require('gulp-develop-server');
gulp.task('default', ['server:start'], function(){
});
gulp.task('server:start', function() {
server.listen({ path: config.server.path});
});
My app.js has this:
var koa = require('koa')();
koa.listen(config.server.port, function(){
console.log('Koa app is listening on port ' + config.server.port);
});
so I'm trying to understand better how node is being started. I see people mention doing it manually like "node app.js". So doesn't koa.listen() automatically do a "node" command to start the koa web server? If I use gulp-develop-server and specify server.listen, isn't that doing 2 server.listen() for node?
Just trying to understand the basics here and can't understand why anyone would manually type in 'node [file with .listen]' manually. I'm not doing that manually and server.listen() obviously uses the 'node' command on my app.js.
Your gulpfile is a Node script. So when you run gulp server:start you're executing a Node application, the gulp command is essentially node plus some extra functionality.
The way gulp-develop-server works is it runs an additional Node application as a child process. server.listen is basically just telling gulp-develop-server what script to run.
The naming is a little confusing, but essentially what's going on is: You have 2 Node applications running on your machine (one that you can see, and one in the background), but only 1 server.
I am running a packaged nodejs webserver that allows for reading of epub files (Readium-JS), and it is started with the grunt command.
However, if I run this on my VPS the server dies as soon as my terminal connection ends.
How can I run this task as a daemon?
I have looked at options like grunt-forever and grunt-daemon but the way the Gruntfile is written using load-grunt-config is messing with my mind and I can't piece together how to isolate the server code.
Here's the solution I found:
As was suggested above, using pm2
However, when I ran
pm2 start grunt
I got an error saying that the grunt module did not exist, which was weird.
So I ended up writing a script which worked:
-- start.js --
var pm2 = require('pm2');
pm2.connect(function() {
pm2.start({
script : '/usr/local/bin/grunt', // Script to be run
args: '--force',
}, function(err, apps) {
pm2.disconnect();
});
});
After running node start.js from the command line, everything sailed smoothly.
Since we can configure socket.io to use redis for it's internal workings like this:
var RedisStore = require('socket.io/lib/stores/redis')
, redis = require('socket.io/node_modules/redis')
, pub = redis.createClient()
, sub = redis.createClient()
, client = redis.createClient();
io.set('store', new RedisStore({
redisPub : pub
, redisSub : sub
, redisClient : client
}));
How is it possible to see inside of this RedisStore to see what data socket.io is inserting and removing. I set my socket.io configuration to use the redis instance installed from node-redis like this:
redis = require('redis')
but I don't see any socket.io activity going on and I wonder if socket.io is actually using redis. I do see my cookies being stored in redis because I configured express and connect to use redis as the MemoryStore, but I don't see anything related to socket.io.
For local redis node.js development/debugging I do this.
Start redis server in background and run the cli monitor in the same tty:
redis-server &
redis-cli monitor -h host -p port
You can leave - switches off if using local defaults.
You can also run a redis slave that echos all master commands and SYNCs the current redis-server's memory held data into a textfile defaulting to ./dump.rdb. The file can be loaded into redis and viewed with a text editor.
redis-cli --slave -h host -p port
vim ./dump.rdb
A basic node.js Passport session-cookie would look something like this:
sess:L2C4MPtAUmlO4zHGkXnq4icuÃ#U#Z{"cookie":{"originalMaxAg null,"expiresÀhttpOnly":true,"path":"/"}passport L}
To further help see inside you may want to step through your app and put breakpoints in the areas where your node code and redis driver interact.
You can use this to watch the handshake process, see incorrect data exchanging, problems with the socket, etc by stepping through your functions, and observing the changes in state during control flow.
The node app for this job is node-inspector.
It will allow you to view your app running in a debugging environment similar
to Chrome dev tools, where you can set breakpoints to pause, step in and out
of functions, and move forward in time until the next breakpoint or exception
triggers a pause.
npm -g install node-inspector
You install it with the '-g' global switch as you use it across multiple projects.
running the program without any options in a terminal window produces this output for me:
~/passaic-streaming git:weekend-refactor ❯❯❯
Node Inspector v0.7.0
Visit http://localhost:8080/debug?port=5858 to start debugging.
You can configure the HOST, PORT, DEBUG-PORT using config or ENV variables
(DEBUG_PORT, port 5858, passed as a parameter sets up a socket connection
between the running node process and your browser running the web-app).
Now, there are three ways to run your node.js code in debug mode. You do this after first running node-inspector:
node --debug-brk app.js
node --debug app.js
node app.js // then send a SIGUSR1 to the node process:
// pgrep node
// kill -s USR1 PID
Use the first command '--debug-brk', until you got everything working, as it tells your code to stop on your module's first line.
browser http://localhost:8080/debug?port=5858
It can take a little time to load depending on your app size. But once there you'll have a source tab to step through code, and a console tab.
The '--debug' will work fine on an express app, you may just need to hit an endpoint or do some transaction or tell it to pause at a breakpoint manually.
Some node scripts are too fast to get caught by the node-inspector listener and until you set up breakpoints in the source code it can be convenient to break on the first line, hence the command.
You can also put 'node debugger';lines around areas like:
// connect to Redis for sessionStore
node debugger; // node-inspector will pause here.
redisClient = redis.createClient(
options.PORT, options.HOST, options.REDIS_OPTIONS));
The main reason you may need to use the SIGUSR1 and not start the app in debug mode is if you are using the node.js cluster API.
If you try to monitor an app that is using clustering and creating multiples node processes, then if you try to debug in node < 0.11.x you'll see this problem with the socket:
Failed to open socket on port 5858, waiting 1000 ms before retrying
Failed to open socket on port 5858, waiting 1000 ms before retrying
In the unstable node versions the child_process.fork command listens on a debugger port 5858+1, so 59, 60, etc, depending on the workers you have.
For now in node 0.10.x if you need to inspect the state of a worker in a clustered app you'll have to start node not in '--debug' mode and instead send the kill USR1 signal to the process.
To coerce more logging out of node with redis put your node_redis driver in debug mode:
redis = require('redis');
redis.debug_mode = true; //turn on debug mode
Also if using connect-redis middleware if you start like this:
DEBUG=* node app.js
Then you will see connect-redis output like this:
connect:redis SETEX "sess:FVDBpNoFDFIOkynFDLcpM6St" ttl:604799
{"cookie":{"originalMaxAge":604799991,"expires":"2014-03-08T22:38:32.620Z","httpOnly":true,"path":"/"},"passport":{"user":"52edfdfdf3da2rer0c06eb34"}} +50ms
Finally, the team at StrongOps/Strongloop has part of their command line tools node-inspector baked in.
npm install -g strong-cli
slc debug app.js
It will boot the node-inspector, open the web browser to the proper inspector, and in the latest node versions -- it understands clustering.