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
Related
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 an electron app where I need not only to run the interface to the user but also start an express server that will serve files for people connected through the network.
I have everything working if I start both electron and the express server normally, but I'm pretty confident that I will need the server running in a different thread to avoid slugish interface and even problems with the server.
For that matter I tried to run my express server using the child_process.fork and it worked when I use npm start, but when I use electron-builder to create an .exe, the installed program doesn't start the express server.
I tried to run my server right away using:
require('child_process').fork('app/server/mainServer.js')
I tried several changes, prefixing the file with __dirname, process.resourcesPath and even hard coding the generated file path; changing the fork options to pass cwd: __dirname, detached: true and stdio: 'ignore'; and even tried using spawn with process.execPath, which will also work with npm start but won't when packaged (it keeps opening new instances of my app, seems obvious after you do hehe)
Note: If I don't fork and require the server script right away, using require('server/mainServer.js') it works on the packaged app, so the problem most like isn't the express itself.
Note 2: I have asar: false to solve other problems, so this is not the problem solver here.
I put up a small git project to show my problem:
https://github.com/victorivens05/electron-fork-error
Any help will be highly appreciated.
With the great help from Samuel Attard (https://github.com/MarshallOfSound) I was able to solve the problem (he solved for me actually)
As he said:
the default electron app will launch the first file path provided to it
so `electron path/to/thing` will work
in a packaged state, that launch logic is not present
it will always run the app you have packaged regardless of the CLI args passed to it
you need to handle the argument manually yourself
and launch that JS file if it's passed in as the 1st argument
The first argument to fork simply calls `process.execPath` with the first
argument being the path provided afaik
The issue is that when packaged Electron apps don't automatically run the
path provided to them
they run the app that is packaged within them
In other words. fork is actually spawn being executed with process.execPath and passing the fork's first argument as the second for spawn.
What happens in a packaged app is that the process.execPath isn't electron but the packaged app itself. So if you try to spawn, the app will be open over and over again.
So, what Samuel suggest was implemented like this:
if (process.argv[1] === '--start-server') {
require('./server/mainServer.js')
return
}
require('./local/mainLocal.js')
require('child_process').spawn(process.execPath, ['--start-server'])
That way, the first time the packaged app will be executed, the process.argv[1] will be empty, so the server won't start. It will then execute the electron part (mainLocal in my case) and start the app over, but this time passing the argv. Next time the app starts, it will start the server and stop the execution, so the app won't open again because spawn is never reached.
Huge thanks to Samuel.
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
I have run into a road block with a new team I am working with that supports a node app. The app is launched via Gulp, and the setup is such that there is a "core" NPM module that defines a bunch of gulp tasks and a "server", and our app simply installs this package and our code is copied in as a "plugin" to the server.
In our gulpfile.js, we have something like:
var gulp = require('gulp');
var workflow = require('base-workflow');
workflow.use({ gulp: gulp });
gulp.task('default'), ['base:default']);
...more stuff
Where base:default is pulled in and a couple of Hapi servers are ultimately started (one as a "web" app, one as the "rest" proxy app to a real Java-based REST services). What I would like to do is setup node-inpector so that I can troubleshoot the startup of the app because I have found that the latest versions of their base packages are not Mac-compatible.
What I have tried is to install gulp-node-inspector with the following changes:
var gulp = require('gulp');
var nodeInspector = require('gulp-node-inspector');
var workflow = require('base-workflow');
workflow.use({ gulp: gulp });
gulp.task('default'), ['base:default']);
gulp.task('debug', ['default'], function() { gulp.src([]).pipe(nodeInspector({debugBrk: true})); });
...more stuff
and also:
var gulp = require('gulp');
var nodeInspector = require('gulp-node-inspector');
var workflow = require('base-workflow');
workflow.use({ gulp: gulp });
gulp.task('default'), ['base:default']);
gulp.task('debug', function() { gulp.src(['default']).pipe(nodeInspector({debugBrk: true})); });
...more stuff
but neither of those works. Part of this is most likely my lack of understanding of Gulp. Does anyone know how I can debug this app?
I spent a fair bit of time googling and trying the various solutions out there; in the end the one that worked for me was the accepted answer found on this page:
How to debug gulpfile.js
This was the only one that allowed me to actually hit my "debugger" command in my gulp task.
I should also note that I had to completely uninstall and reinstall "node-inspector"; there was a version problem and when I was on the verge of solving it I was getting some "cannot find module" error because the version of node-inspector was causing it to point to the wrong folder. Once I uninstalled and reinstalled (via npm) then it worked. In my case I'm on a Windows machine and the command that worked looked like the following:
node-debug C:\myPathWhereGulpfileDotJsExists\node_modules\gulp\bin\gulp.js --gulpfile C:\myPathWhereGulpfileDotJsExists\gulpfile.js myTestTaskContainingDebuggerCommand
Maby this solution help you
node --inspect --debug-brk ./node_modules/gulp fonts
The best way to do this now is to add a debugger; to the place in the file you would like to add a breakpoint to, or set it manually once the debugger has started with setBreakpoint('gulpFile.js', 1)
Then simply
node inspect --inspect-brk $(which gulp) taskName
c
More information about debugging with node here
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.