Fix for issue causing subprocess to never end

[ffMathy]

fixes #23 and #29.

For some reason, if buffer is set to false, the await subprocess call never ends, no matter if the test passes or not.

See #29 for steps to reproduce in this very repo.

[sindresorhus]

This might be an execa bug. I don't think we want to set buffer: true could potentially make it run out of memory when using the watch option.

// @ehmicky

[ffMathy]

This was an interesting read that also contains workarounds.

sindresorhus/execa#350

However, it also seems to introduce an "all" option that introduced the issue in the first place from what I can gather, since a default behavior was changed.

[ffMathy]

@sindresorhus more research lead me to this, which awaits your response:

sindresorhus/execa#351

I think the next major release includes a fix, and they are considering making that release now.

[ffMathy]

Is there anything I can do to help out?

[novemberborn]

Is there anything I can do to help out?

With execa, or here? I don't use Gulp but happy to take a PR that makes it work better.

[ffMathy]

I'm just interested in helping wherever I can, to get this bug closed. It's currently messing with our build pipeline.

[novemberborn]

Sorry to hear that. I don't really have a view on what's needed to fix this, but again happy to take a PR. It sounds like we need to wait for an execa release?

[ffMathy]

Yeah, unless we can merge this PR or make a workaround of some sorts.

[novemberborn]

Can you install gulp-ava from your GitHub branch and use that to unblock your build pipeline?

[ffMathy]

That's a great idea! Will do that until then, but I'm still afraid we'll forget to change it back later.

[ffMathy]

@novemberborn @sindresorhus I changed the solution to add a "hack" that will work around the bug in execa.

I don't think it's that ugly, and it solves the issue, while still allowing buffer to be false.

If you want, I can also add a comment in the code referring back to this issue.

Please have a look and let me know what you think 😄

[ffMathy]

Let's close this in favor of #31!