process.on("exit", fn) not being respected

[cowboy]

See sindresorhus/time-grunt#15.

Given the following code:

console.log("before");
process.on("exit", function() {
  console.log("on exit");
});
process.exit();
console.log("after");

• In non-Windows Node.js, this properly logs before then on exit.
• In Windows Node.js, this might log nothing, all three things, or some combination of them. Kinda random, depends on the shell, if output is piped or not, etc.
• With require("exit")(); instead of process.exit(); only before is logged. on exit should be logged.

Take a look at this commit in the node-exit branch.

Granted, that code is currently failing... but if we can fix it, we might be able to allow @sindresorhus's plugin to continue working.

Possible solution: Set stream.write to a NOP function after the exit event has been called?

[vladikoff]

Specific issue we found, running this with output redirection:

console.log("before");
process.on("exit",function(){console.log("on exit");});
process.exit();
console.log("after");

PowerShell ignores "on exit"

[cowboy]

Rebased on top of 0.1.2 via e90e70e.

[cowboy]

In 0778a33 I've overridden process.emit, which should allow synchronous stdout / stderr writes inside process.on("exit", fn) to work, while still preventing "after" from being written in the original example.

Thoughts?

/cc @sindresorhus

[alimfeld]

@cowboy I'm confused... maybe you can shed some light on this:

As I understand it, using require("exit")() instead of process.exit() changes the exit semantics. The first allows following statements to be executed (until actual process.exit() is called), while the latter doesn't.

Consider the following case:

if (shouldExit) {
  require("exit")(errorCode);
}
// assume we can continue
doContinue();

If I'm not mistaken, doContinue may be called in this case but it would never be called when using process.exit(). Shutting down stream writes seems random to me, as it only tries to keep the exit semantics for stream writes but not for all other code that may be executed. I'm sure I miss something here...

[cowboy]

I dunno.

[alimfeld]

Opinions? (Sorry to keep bothering...)

Why is it a good idea to prevent further writing to streams in node-exit?

(I feel it causes more harm than good as it breaks process exit handlers writing to streams and somehow tries to conceal the changed exit semantics of node-exit).

[cowboy]

I'm operating under the assumption that once process.exit() is called, nothing after that except things in process.on('exit', fn) handlers should run.

Does that seem fair?

I was addressing the part of that assumption that deals with output stdout and stderr logging, since that's how this issue manifests itself in my code. I'm not sure how to handle anything other than that.

[vladikoff]

@alimfeld the goal is to eliminate inconsistencies, I believe if streams are allowed then you get different outputs between UNIX and Win32. So currently the plan is try and find a way to make node-exit capture the process exit

[alimfeld]

@cowboy fair enough... thanks for clarifying 😄

[pifantastic]

0778a33 works for me!

We use time-grunt as well as a custom plugin that formats things for teamcity (using a method similar to time-grunt. Would love to see this land!

[sindresorhus]

Any new ideas on this? It's been a while.