fix: make verifyAndReceive accept a string name.

[jyasskin]

As naturally comes from the relevant HTTP header.

Resolves the easy half of #1055

---

Before the change?

• Callers have to do an unchecked cast from string to either any or the unexported WebhookEventName type.

After the change?

• Callers can pass the HTTP header directly into verifyAndReceive()

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
  Kinda: I removed the cast from the middleware, so it'll break if the stricter type is re-introduced.
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  This type constraint doesn't seem to have been documented.

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[wolfy1339]

The WebhookEventName is actually exported in the types.ts file.

import type { WebhookEventName } from "@octokit/webhooks/types";

Note: there is no file extension on the import path

[github-actions]

🎉 This PR is included in version 13.4.3 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀