v2

[sindresorhus]

@ehmicky Is there anything you think we should improve with the API? Since it's a major version, we can do breaking changes if it's beneficial.

[sindresorhus]

I have created a v2 milestone: https://github.com/sindresorhus/execa/milestone/1

[ehmicky]

It seems this major release already has lots of improvements, so this looks good to me. From a developer experience standpoint nothing comes to my mind.

The milestone issues and PRs to work on look good.

[sindresorhus]

I also want to make .signal be undefined instead of null when not available. I'm trying to limit my null usage for consistency.

execa/index.js

Line 164 in 7f8d911

error.signal = signal || null;

[ehmicky]

I can open a PR to remove null from signal.

null is also set to result's stdout, sderr and all when standard streams options are set to either null or undefined. Should that be removed as well?

[sindresorhus]

Yes

[ehmicky]

Done in #193.

[arcanis]

Please please please do something about preferLocal 🙏

Yarn already sets the PATH when running scripts so that the right Yarn binary (and all other binaries that your application should have access to) is always in the PATH. But because execa modifies it as well (and it does it without actually knowing which paths it should use, it only makes assumptions), it ends up overriding the Yarn-generated folder. In the end, the wrong files are called.

I would strongly suggest defaulting it to false, as it's very intrusive and can lead to pretty hard to debug issues (I myself spent an indecent amount of time trying to figure out what happened before I started to consider that maybe execa was doing something strange).

[ehmicky]

@arcanis thanks for reporting this. Is there already a GitHub issue about this in this repository? If not, this might be better to open a separate issue. Also some minimally reproducible code would us help out with this problem.

[arcanis]

@ehmicky sure, I put more details on #196

[ehmicky]

@sindresorhus Should we do a beta release right away? Without updating the latest npm tag. Like this, as we are waiting for the few items left to be merged, some users can try it out. There are quite many breaking changes, so it might be a good idea to avoid too many issues during the public release.

Also: should we add any of the new PRs to the v2 milestone?

[sindresorhus]

Should we do a beta release right away? Without updating the latest npm tag. Like this, as we are waiting for the few items left to be merged, some users can try it out.

From experience, there's not much point. I tried doing prereleases many times in the past and nobody bothered to try it out (I know because the prerelease was broken, but nobody reported it). If someone wants to try it, they can just npm i sindresorhus/execa anyway.

[arcanis]

So #196 won't be part of the release? 🙁

[ehmicky]

The reason I was asking was also because:

• I am currently working on a Gulp plugin for Execa and right now I've done npm i sindresorhus/execa#c8a53da6748885423f73812580afd59699b36e31. This works though for the moment.
• We've had several issues where people were wondering why they can't use some of the new features (like TypeScript). This would solve this problem until we get the major release ironed out.

[sindresorhus]

We've had several issues where people were wondering why they can't use some of the new features (like TypeScript). This would solve this problem until we get the major release ironed out.

It probably wouldn't as they would not get the new version by default, so they would still open an issue, and we would have to tell them how to install a prerelease.

[sindresorhus]

So #196 won't be part of the release? 🙁

We intend to solve it, but it's a complex issue with no clear outcome that satisfies all parties...

[ehmicky]

There's an alpha version of v2 out now: https://github.com/sindresorhus/execa/releases/tag/v2.0.0-alpha.0

Install it with npm install execa@next.

Please share feedback here or in new issues.

[ehmicky]

We just released 2.0.0. Please check the Medium article!