workarounds for browserify

[danielepolencic]

fixes #24

• if stderr is not available, inject the console in squeak
• process.exit is not available in the browser. Don't call the method if it is not available.

[sindresorhus]

I still think this is better fixed in squeak: #24 (comment)

[sindresorhus]

How will this work with hihat? According to its docs:

The process will stay open until you call window.close()

Wouldn't it be better to call window.close here if in the browser. Or even better, keep it as before, and have hihat shim process.exit => Experience-Monks/hihat#27

[sindresorhus]

// @mattdesl

[mattdesl]

Hmm.. window.close would also work with smokestack but it seems like a pretty big assumption.

In hihat the goal is interactive testing (fast save -> reload workflow). If ava exits the process on fail, it would break this development cycle. Maybe ava should not quit at all in the browser?

[sindresorhus]

@mattdesl Good point. So what should we do here?

[Qix-]

Hmm. Perhaps ava.on('exit', ...), where ava detects if it's in node and registers the default handler of process.exit()? Let test implementers decide; we can add sensible defaults as necessary.

[Qix-]

Or even shim process.exit()? It fires the exit event (process.on('exit', ...)) so that might even be the ideal way anyway to keep full compatibility.

[vadimdemedes]

Agree with @mattdesl, on client-side process.exit() should do nothing or send an exit event, but definitely not close a window.

[mattdesl]

It seems sorta weird that an API would ever call process.exit. I feel like this should be left up to the user.

I feel like only the CLI should exit and handle errors itself, since in that case the user isn't handling them.

[vadimdemedes]

@mattdesl this happens, because we want to cover a case when test is being executed directly.

$ node test-something.js

So if only CLI would use process.exit(), in the above case process would exit always with zero (success).

[mattdesl]

I see. It's a bit of a special case then.

[arthurvr]

Or even shim process.exit()? It fires the exit event (process.on('exit', ...)) so that might even be the ideal way anyway to keep full compatibility.

To me that sounds the most reasonable way to me. Though I guess this is kind of a rare case anyways.

[Qix-]

It is, but it's still probably the correct way. Just a thought.

[scottcorgan]

Just curious if there's been any progress for the browser. Only thing keeping me from Ava.

[sindresorhus]

@kevva said he would make squeak browserifyable and this PR needs to be updated to only include the exit change.

[sindresorhus]

Might be more, though, as we recently introduced parallism, which forks the processes. Not sure whether browserify handles that or if we need to do some special casing. Help welcome. Our main focus is elsewhere.

[kevva]

Browser support in squeak is fixed in kevva/squeak@fd7333e.

[kevva]

... this PR needs to be updated to only include the exit change.

So what should we decide on? Just check for process.exit and do nothing if it doesn't exist?

[sindresorhus]

Closing in favor of #97.