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

@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.

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

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

a minor version seems ok

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

Thanks everyone. This feature has landed in 14.1.0.

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

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

woot, thanks! 🎉

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?

@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?)

@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).