add execa.stdout() shortcut

[sindresorhus]

Not sure about this one. The thinking is that stdout is the most common use-case so might be nice to have a shortcut for it. This is not about the amount of characters, as that's mostly the same, but rather clarity.

Example:

test(async t => {
    t.is((await execa('./cli.js')).stdout, 'foo');
});

test(async t => {
    t.is(await execa.stdout('./cli.js'), 'foo');
});

You can see how the second one is more readable because of less parens.

@kevva @SamVerschueren @jamestalmage @novemberborn Could use your opion 🙌

[jamestalmage]

The one advantage to the first, is that power-assert will show you the output of stderr in the graph. If you do this, you might as well create the equivalent stderr shortcut. Just so it's easy to flip a test to print stderr instead of stdout without reworking your call structure.

[sindresorhus]

Sure, I guess I could add that, but the important question is; Do you think this is a valid addition?

[kevva]

Regardless of the parens, I actually don't think one way is more clearer than the other. The first example is how I would expect it to work, the latter one would just be a nice shortcut. I could live without it.

[jamestalmage]

I don't think it's that helpful, but I haven't written a lot of tests using it.

[novemberborn]

Alternatively change the execa return value to be a decorated thenable, e.g. add a stdout getter that returns a promise:

test(async t => {
    t.is(await execa('./cli.js').stdout, 'foo');
});

[jamestalmage]

I think Mark's idea is the best so far.

[jamestalmage]

Note: it needs to be implemented as a getter that defers creation of additional promises so you don't end up with unhandled rejections.

[sindresorhus]

I think Mark's idea is the best so far.

Why is it better?

Alternatively change the execa return value to be a decorated thenable, e.g. add a stdout getter that returns a promise

What if you want both stdout and stderr at the same time? Not easily doable, unless I'm missing how this will work.

[jamestalmage]

Why is it better?

Subjective, I like the trailing .stdout - it reads like synchronous code.

What if you want both stdout and stderr at the same time?

both:

const {stdout, stderr} = await execa('./cli');

Just one:

const stdout = await execa('./cli').stdout;

---

Or maybe just leave it as is:

const {stdout} = await execa('./cli');

[sindresorhus]

How can const stdout = await execa('./cli').stdout; both be a string and promise?

[jamestalmage]

It can't - it would always be a promise.

[sindresorhus]

@jamestalmage But, then your example wouldn't work:

const {stdout} = await execa('./cli');

stdout is a string here.

[jamestalmage]

Both would work - the await is evaluated before the assignment:

const {stdout} = await execa('./cli');
// =>
const {stdout} = await Promise.resolve({stdout:string, stderr: string});
// =>
const {stdout} = {stdout: string, stderr: string};
// => 
const stdout = string

and

const stdout = await exec('./cli').stdout;
// =>
const stdout = await Promise.resolve(string);
// =>
const stdout = string;

[jamestalmage]

See jamestalmage@70629c6#diff-1dd241c4cd3fd1dd89c570cee98b79ddR115

It can definitely work both ways. Still, not sure it's the best idea

[jamestalmage]

My new preference is to merge this, and #18.

#17 was a fun idea, but it conflicts with #18, which I think is more important.

[sindresorhus]

So if we're going with this it would be execa.stdout() and execa.stderr(). I'm not so sure anymore it's worth the extra API bloat and potential confusion. We now have two very similar ways to get stdout/stderr.

[jamestalmage]

One potential advantage: #18 (comment)

Ignoring the stream you don't care about improves memory efficiency.

[sindresorhus]

Another argument for adding this. When returning the result of execa and you only want stdout you currently have to do:

return execa('bin').then(result => result.stdout);

This would be nicer:

return execa.stdout('bin');

[sindresorhus]

@jamestalmage Ready for review.

[sindresorhus]

Deferring this until #24 is done.

[sindresorhus]

Thanks for the great feedback :)