5

I am not sure if this is purely Windows issue. I don't have option to test anywhere else. Given this really simple code (Coffeescript):

console.log('Calling console.log')
console.error('Calling console.error')
console.log('Calling console.log second time - fails')
console.error('Calling console.error second time - fails')
nonexisting.throwError()

Running it directly with coffee app.coffee it works just fine and I get this:

Calling console.log
Calling console.error
Calling console.log second time - fails
Calling console.error second time - fails
ReferenceError: nonexisting is not defined
....

However running nodemon app.coffee gives me just this:

17 Mar 20:38:56 - [nodemon] starting `coffee.cmd server.coffee`
Calling console.log
Calling console.error
17 Mar 20:38:56 - [nodemon] app crashed - waiting for file changes before starting...

Not only there isn't exception info at all, but also later log messages are swallowed for some reason. In more complex scenario I have no method to actually find the reason of crash. I tried to debug, but everything seems fine, console.log/error is called, but it's just not displayed for some reason. And exception is caught by Coffeescript and send directly to stderr.

I wanted to use debug utility to have nice verbose output during development in the console and make it easier to find issues. But with this troublemaker it's not possible. Once uncaught exception occurs, I have to stop nodemon and run whole thing manually to find the error. All the elegance of the solution goes away with this :(

Anyone have idea what could be causing this and if there is some possible solution ?

Windows 7 64bit Node 0.10.26 Nodemon 1.0.15 Coffeescript 1.7.1

FredyC
  • 3,999
  • 4
  • 30
  • 38
  • Can you try running `nodemon --nodejs --debug app.coffee` and see if anything changes? – mutil Mar 17 '14 at 22:00
  • 1
    I run this coffee file with `nodemon`, `forever`, `node-supervisor`, and `node-dev`. `pm2` is not tested because I can't install it on my windows laptop. Only `node-dev` can output the desired message. Ref: [Comparison: Tools to Automate Restarting Node.js Server After Code Changes](http://strongloop.com/strongblog/comparison-tools-to-automate-restarting-node-js-server-after-code-changes-forever-nodemon-nodesupervisor-nodedev/) – bnuhero Mar 17 '14 at 22:28
  • @mutil No change except node debugger kicks in. – FredyC Mar 17 '14 at 22:37
  • @bnuhero Thanks, I will give the node-dev a try. – FredyC Mar 17 '14 at 22:38

2 Answers2

4

The messages are being suppressed because the process is spawned using:

child_process.spawn('coffee.cmd', ['server.coffee'], { stdio: ['pipe', 'pipe', 'pipe']);

In particular the pipe on stderr is the issue, because when the child exits, the pipe is full (or appears to be from the first console.error) so the next message isn't put in the pipe when the child dies.

I've updated nodemon to be smarter about when it uses pipe, because in most cases, using process.stdout on stdio works just fine, and also means this original example script echos out the errors as you'd expect.

The issue you filed has also be closed in nodemon@1.0.17

I should add, the title of this SO question is misleading (it reads as if nodemon hides all console output) - it doesn't hide console output - it was losing console output when the process was crashing. None the less, it's fixed - yay!

Remy Sharp
  • 4,520
  • 3
  • 23
  • 40
1

I have an hint, but cannot prove my feeling.

When executing your program with coffee, the log messages are blocking. The error at line 5 occured while the 4 traces were already issued to console.

Whatever the monitoring tool used, the principle are nearly the same: spawn a child process that will host your app and monitor its lifecycle. It means that your console output is redirected from the child process to the host one, that displays it.

I bet that the failure is processed prioritaryto the log messages, and thus, the host process cuts the channel before having time to display the remaining logs.

Feugy
  • 1,898
  • 14
  • 18
  • That actually makes sense, thanks. So it's more likely a bug in the tool then anything that I can do about. – FredyC Mar 18 '14 at 21:50