Add documentation for stub.yieldsRight

[nivsherf]

Purpose (TL;DR) - mandatory

Adding missing documentation for stub.yieldsRight.

How to verify - mandatory

1. Check out this branch
2. npm install
3. Review the stub docs.

Checklist for author

• npm run lint passes
• References to standard library functions are cached.

[coveralls]

Pull Request Test Coverage Report for Build 2638

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.324%

---

Totals
Change from base Build 2635:	0.0%
Covered Lines:	2029
Relevant Lines:	2083

---

💛 - Coveralls

[mroderick]

Thank you for your pull request. This looks good to me. Would you mind also folding the changes into the older versions for which this applies?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nivsherf]

@mroderick Done. (Better late than never...)

[fatso83]

Thanks, @nivsherf. We know the "apply the change to older releases" step is troublesome. Did you find a way that made the process more slick for you? Would like to find some (semi-)automatic way of applying a patch to the older release docs.

[nivsherf]

@fatso83 Well, in this case a simple replace did the trick. But since you asked, I also wrote a bash script that given a doc section and a semver number (e.g "stubs" and "4.1.1") will open the editor to edit the .md file for that version, then recursively do a 3-way merge on subsequent versions, stopping on conflicts so you can resolve them. A bit like "rebasing" the versioned docs. It's very basic and very poorly tested - mostly just a POC for myself... but I can share it if you're interested.

[fatso83]

This is our weakest point, and increasingly a pain point, so if you could share the script in gist or something, that would be great.

[nivsherf]

@fatso83 Here's a gist.

[nivsherf]

Here is another version which works the other way around - it assumes changes were already made in release-source/ and propagates them to older versions. I guess this better fits your use-case, although it makes the conflict-resolution a bit less intuitive. Also handles editing the release.md file, which the previous version did not.