feat: Add more thread context preserving combinators

[OlaoluwaM]

No description provided.

[pbrisbin]

LGTM, but this is an addition, which would be feat:, not refactor:.

(We're also not using semantic-release in this project yet, FYI)

[pbrisbin]

Just a further note about conventional-commits, since I've been reading up on it and we may start using it more...

You can't just make up any prefix like refactor: or ci:. The team would have to agree on a convention (one we make up or one we adopt). By far the most common is Angular, which only has chore:, fix:, or feat:. I see no real reason to deviate.

You do, however, have (scope) available. So you'd probably want to do chore(ci): instead of ci:.

I think that even if we adopt a loose "use conventional commits if you want", those commits that are doing so should probably do so correctly.

[pbrisbin]

That said, just because you were making that commit in response to a CI failure, that doesn't mean the change itself has anything to do with CI, such as working on the workflow itself (which is what I'd take chore(ci): to mean). Those commits might be best prefixed by chore(http):, but I usually just do chore: anyway for anything that doesn't change library API 🤷

This stuff is tricky!

[OlaoluwaM]

You can't just make up any prefix like refactor: or ci:. The team would have to agree on a convention (one we make up or one we adopt). By far the most common is Angular, which only has chore:, fix:, or feat:. I see no real reason to deviate.

My bad, I've always used these prefixes since they seem to be recommended in the conventional commits spec. It's something I've always done. I have a git commit message template with all these things outlined so I've made a habit of just picking based on context/occasion, but I guess now that we're trying to adopt this style commit messages at an org level, I ought to have asked/looked into the particular variant we're looking to follow.

[OlaoluwaM]

That said, just because you were making that commit in response to a CI failure, that doesn't mean the change itself has anything to do with CI, such as working on the workflow itself (which is what I'd take chore(ci): to mean). Those commits might be best prefixed by chore(http):, but I usually just do chore: anyway for anything that doesn't change library API 🤷

Yeah, the spec is pretty open-ended about the meaning of prefixes beyond "fix", "feat", and "BREAKING CHANGE", so I can easy how it might be easy to have conflicting definitions

[pbrisbin]

used these prefixes since they seem to be recommended in the conventional commits spec

Aha, see this is why I make these comments. I never saw this,

types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

Nevermind then, TIL!