chore: release

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@slack/webhook@7.1.0

Minor Changes

• 59124ef: feat: export addAppMetadata for external instrumentation use

@slack/web-api@7.17.1

Patch Changes

• 59a6329: fix: update SlackListsItemFieldMessage to support single and array message shapes

[mwbrooks]

@zimeg Should these release PRs be opened as draft? Right now, they immediately notify the reviewers but it doesn't looks like we're intending to release yet.

[zimeg]

⚠️ Hold before cutting @slack/web-api@7.17.1 — the queued #2627 changeset has a likely breaking request-side regression.

#2627 fixed the Lists message response shape, but changed it on the shared SlackListsItemField type:

message: string[]  →  SlackListsItemMessage | SlackListsItemMessage[]

That union type backs both directions:

• request — SlackListsItemsCreateArguments.initial_fields (slackLists.items.create / .update)
• response — SlackListsItem.fields

Per the docs, the request message field is an array of message permalink URL strings:
https://docs.slack.dev/reference/methods/slackLists.items.create/#field-types

So this patch now mistypes valid request input — anyone passing message: ["https://…/p123"] to initial_fields gets a type error. Because it removes a previously-accepted request shape (string[]), this is arguably a breaking change, not a patch-level fix.

Recommendation: split the request vs. response message field types before release — request keeps string[], response gets the object union — per the approach in #2600. Happy to fast-follow with that fix; flagging here so 7.17.1 doesn't ship the regression silently.