Write to temp outfile until success, fixes #899

[natevw]

Write browserify command output to a temporary file, overwriting the target file atomically upon success (and simply cleaning up the tempfile on error).

This has two benefits:

• user won't be left with an empty file if compilation fails (which can break toolchains that rely on destination files/timestamps to indicate build status, Make or django-pipeline for just two examples) i.e. fixes Browserify should not create empty output files on error #899
• output file can never end up in a half-written state during even a successful compilation

[ghost]

This patch looks good to me. Do you think this change should be a major or minor version bump?

[natevw]

@substack Hmmm, that's a good question. Given that this behavior wasn't documented [afaik?] and wasn't usually useful [imo], I'd call it a bug fix. But technically it does change the external behavior of the CLI tool, and therefore could conceivably break a build process that relies on the "empty file" behavior.

[natevw]

@feross @substack Any chance this could still get snuck into the major bump to 14?

[feross]

I'm fine considering this a patch or minor version, and doing a release. But would like confirmation from @substack that he agrees.

[ghost]

a minor version seems ok

[feross]

I actually don't have the time to do a release right now, sorry. Another maintainer want to take this?

[ghost]

Thanks everyone. This feature has landed in 14.1.0.

[ljharb]

The module-deps upgrade is a breaking change; node 0.8 doesn't have setImmediate. Please revert ASAP in the 14.x line.

[ghost]

This was fixed in 14.1.1 by using process.nextTick(). Thanks for catching this @ljarb.

[ljharb]

woot, thanks! 🎉

[benwiley4000]

Looks like #1746 is related to this one (bundle write to temp file fails, but only if package.json has a "browser" field, and "main" is set equal to the source file). Any ideas why?

[natevw]

@benwiley4000 I do not know why this would cause your issue, though I can't claim to fully understand your setup either. (Hopefully there's no internal code that tries to open the [eventual] output file for reading before it is finished being generated?)

[benwiley4000]

@natevw yeah, I'm not sure why either - I just know that when I was testing, I was able to reliably pinpoint the bug's origin with a before/after.

If you're curious about a repro, try running npm run build on this repo: https://github.com/benwiley4000/gif-frames

It should work find as-is, but if you change the name of the bundled field in package.json to browser it should fail (keep in mind that when browserify consumes a module it looks for the browser field so this could be related somehow).