Why the tmp stream? Instead of:

try {  fs.unlinkSync(outfile); } catch(err) { }

Generic answer : I personally hate software which does what it wasn't asked to do :-)
Specific answer: if, for whatever reason, the output file did exist before the browserify run it will get deleted without advance warning. So I check if the file exists before attempt to run and clean up after the failed run only if there was no output file before.

Ah makes sense. The fs.createWriteStream(outfile) will write to the file (thus emptying it if it existed before) pretty much always before any error ever gets emitted by browserify. But at least you're leaving the file behind. Ok cool, but that tmp stream 🙀

var outfileExists;

if (outfile) {
    try { outfileExists = !!fs.lstatSync(outfile); } catch (err) {}
    bundle.pipe(fs.createWriteStream(outfile));
}

makes sense, thanks. Updated.

I'm against adding .sync calls. This patch also seems to add a lot more complexity that will probably break in strange ways. Writing to a tmp file was removed from watchify for this reason since it kept breaking on windows. I'm skeptical that this kind of patch won't ripple up to create problems.

@substack, are you against this PR entirely, or just against replacing the test for existence by opening the stream with lstatSync()? Without this PR (or equivalent) browserify breaks make-based workflows and forces use of make kludges like DELETE_ON_ERROR which do not exist in all flavors of make

It looks like #899 was addressed by #1673. Thanks!