v2 release post and changelog

[ehmicky]

I've created a Medium article for the upcoming major release (#191). Feel free to leave private notes on it if you think some sentences should be reworked or something is missing/wrong! It will remain in draft mode until 2.0.0 is published to npm, so please do not promote that link yet.

I'm also working on the changelog that we could include as the GitHub release description. I will update this post as new commits come in. Feel free to comment on it as well. Here it is:

---

Thanks to @GMartigny, @BendingBender, @tomsotte, @ammarbinfaisal, @zokker13, @stroncium, @satyarohith, @bradfordlemley, @coreyfarrell, @brandon93s, @dtinth, @papb for the great features and bug fixes they've contributed!

Please check the Medium article about this release!

Breaking changes

• Drop support for Node.js 6 (dce22670, #221)
• Remove execa.shell() and execa.shellSync(). The shell option should be used instead. (#219)
• Remove execa.stdout() and execa.stderr(). childProcessResult.stdout and childProcessResult.stderr should be used instead (#234)
• Remove error.code (number or string) in favor of error.exitCode (number) and error.exitCodeName (string) (#187, #250)
• Rename stripeEof option to stripFinalNewline (f8397ba9, 4d0dc88a, #238)
• Rename cmd (in childProcessResult and error) to command (#194)
• Default preferLocal option to false. If you are executing locally installed binaries, you'll need to manually specify preferLocal: true (#314)
• Ensure windowsHide option is always true, so that no window pops up on Windows. (8c886452)
• error.signal is now undefined instead of null when no signal was used (#193)
• Set error.killed to false when child process timed out (#227)
• Make error.killed always boolean (not undefined) (#229, #248)
• Ensure errors always have the same shape. (#276, #277, #283)
• error.stdout and error.stderr are now an empty string (instead of null) when the command failed. (#246)

Features

• Add TypeScript definition (#188, f2cb86ff, 7702b8ef, 4692dcd4, #251)
• Add execa.command() and execa.commandSync(). Those are the same as execa() except both file and arguments are specified in a single string. For example, execa('echo', ['unicorns']) is the same as execa.command('echo unicorns') (#182, #261, #262, #278, #279, #282)
• Retrieve interleaved stdout and stderr with childProcess.all and childProcessResult.all (#171, #264)
• Add execa.node() which (like child_process.fork()) allows you to execute a Node.js script as a child process (#200, #297, #299, #302, #303, #305, #306).
• If childProcess.kill() does not terminate a child process after 5 seconds, force it by sending SIGKILL. This can be configured using the forceKillAfterTimeout option. (#208, #272, #273, #280, #284, #285)
• Add childProcess.cancel() and error.isCanceled (#189, f24e7c72, #226, #309)
• error.stdout, error.stderr and error.all now contain the data that was sent before the child process exit. (#271)
• Improve error.message on child process failure (#180, #223, #230, #245, #269)
• Add .finally() to the child process promise (#174, 65139849)
• Increase maxBuffer option default value from 10 MB to 100 MB (#286)

Bug fixes

• Fix timeout option not working as expected (#199)
• Fix error.timedOut not working with execa.sync() (#249)
• Fix maxBuffer errors not using the same shape as the other errors (#266)
• Fix extendEnd option not working with shell option (#184)
• Fix stripFinalNewline option not applied on error properties (#240)
• Fix /q parameter not added when using cmd instead of cmd.exe (#203)
• Fix uncaught exception when using input option with a non-executable file (#212, #258)
• Fix errors on child processes waiting for stdout/stderr to complete (#270)
• Fix validating that the stdio option cannot be used together with stdin: 0 (#301).

Documentation

• Improve documentation (#158, #235, #237, #239, #241, #256)

Design

• Add a logo (#201)

Tests

• Fix various tests (f185a0e8, #185, #215, #216, #224, #218, #225, #231, #233, #247, #300)

Maintainers

• Add @ehmicky as an additional maintainer.

[sindresorhus]

This looks great. Thanks for doing the work. I've added a couple of comments to the Medium draft, but it's already awesome.

Migrate from AppVeyor to Travis CI for Windows (#167)

This is not really relevant to the user.

[ehmicky]

Thanks a lot! When we do the major release, could you please:

• Give me some heads up, so I can publish the Medium article at the same time. I will also promote it on social media (anyone involved in this release will be welcome/encouraged to do so as well!)
• Copy/paste the CHANGELOG from the first comment (I update it on every new commit) to the Releases notes.

[sindresorhus]

@ehmicky Or better yet, you can do the release? ;) (You have publish access) When we're ready, just do np and then choose major.

[ehmicky]

Do I have npm publish access? If I do, then yes I can do that :+1:

We still have few items in the milestone though.

[sindresorhus]

Do I have npm publish access?

Yes

[magicdawn]

The readme doc has changed but the new version has not been released 😞

[ehmicky]

@magicdawn hold on tight, we're working on that next release :)

[sindresorhus]

@magicdawn That is how most project on GitHub works. If you want docs for the latest version on npm, you go to the specific Git tag or the npm page.

[lolipop99]

@magicdawn hold on tight, we're working on that next release :)

@ehmicky when will the new version be released。expecting... thx

[ehmicky]

@lolipop99 thanks for your interest in the new version! We don't have a deadline (like most open source projects). We have a list of items until the release though: you can follow this milestone.

[magicdawn]

@sindresorhus I get the point. But I guess point out the readme is for the next version like got do will be a great help to users.

[sindresorhus]

@magicdawn No. That's just enabling users to not know how things work. I added it to the Got readme because I knew it was going to come up, but I wish I hadn't. People should learn how GitHub works.

[ehmicky]

I agree with @sindresorhus that when I get on a GitHub repository which shows different documentation for different versions, I find it a little confusing. Instead I'm always assuming the documentation is of the latest version.

Now this assumes versions are released fast, which has not been the case for this major release. The problems are: 1) we have been working on several breaking changes at once. Those should be mostly solved now except for #271 2) we have few big PRs that have taken some time to review 3) we have a hard-to-resolve issue at https://github.com/sindresorhus/npm-run-path/pull/5 that's in a deadlock at the moment

[DavidWells]

Awesome work on this!

Was trying to use execa.command and it wasn't working. Realized I was on v1.0.0 😅whoopsies

Ya'll rock! Excited for release on npm

[tunnckoCore]

Cool. Sounds like a big one! :tada:

In the past 2-3 years, I was maintaining execa-pro/@tunnckocore/execa exactly because of the .command thingy and the ability to pass multiple commands as array of strings (meaning they will run in series - example), it was just a thin wrapper around 30 lines.

And the #153 was the reason to use .shell when needed.

Waiting for that release for sure! :taco:

[ehmicky]

@tunnckoCore great to hear! Feel free to checkout our implementation for execa.command() (it's only 15 lines of code here) and post an issue/PR if you think there's anything wrong with our current solution!

[tunnckoCore]

Yea, I've seen it, it looks like the same thing, I will try it. I'm jumping around the npm-run-path problem now :)

[sindresorhus]

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.

[tunnckoCore]

Sweeeet! :taco: :tada:

Works great for now.

[ehmicky]

We just released 2.0.0. Please check the Medium article!