Browserify should not create empty output files on error

[mietek]

When an error occurs, Browserify 5.11.2 creates an empty output file. This should not happen, as it messes up make-based workflows.

$ cat >foo.js <<EOF
var quux = require('quux');
EOF

$ browserify foo.js -o bar.js
Error: Cannot find module 'quux' from '/private/tmp/foo'
    at /usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:50:17
    at process (/usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:119:43)
    at /usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:128:21
    at load (/usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:60:43)
    at /usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:66:22
    at /usr/local/lib/node_modules/browserify/node_modules/resolve/lib/async.js:21:47
    at Object.oncomplete (fs.js:107:15)

$ ls -l | grep bar.js
-rw-r--r--  1 mietek  wheel   0 13 Sep 14:53 bar.js

[asadovsky]

+1, this behavior is quite annoying.

[rla]

+1, as a workaround, those who use GNU make, just add .DELETE_ON_ERROR as a target https://www.gnu.org/software/make/manual/html_node/Special-Targets.html

[kika]

I'm offering a PR for this
#1239

[natevw]

Looks like the proposed fix for this wasn't a great solution. Seems to me the proper way to handle this would be:

1. Create a temporary file
2. Output the work to this file
3. When/if successful, move the temporary file to the actual path

This is ± how e.g. Cocoa does atomic file overwrites [in that case the temporary and target files need to be on same volume, doesn't seem quite as important here just to fix this issue so long as you avoid/handle the EXDEV error that rename(2) would give e.g. by writing the temporary file in the same place as the actual destination but with a unique suffix].

[natevw]

(Alternate pull request submitted.)